git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [release-plugin] Preparing for 1.4.


On Wed, Aug 22, 2018 at 7:53 AM Rob Tompkins <chtompki@xxxxxxxxx> wrote:

>
>
> > On Aug 22, 2018, at 9:38 AM, Gary Gregory <garydgregory@xxxxxxxxx>
> wrote:
> >
> > Wait a second. If we are talking about our own release plugin, I think we
> > have a different beast here since this is only used by us. BUT... I like
> > consistency, so we might as well eat our own dog food. For major version
> > changes that break BC we must change both the artifact ID and Java
> package
> > name. Check?
>
> Right. My argument is that if we break BC even with a maven-plugin, that
> we should work our hardest to adhere to the principles for external
> artifacts too. Also, we don’t know who else might be using the component
> even though our intent is for only us to use it.
>

OK, then let's play by our rules even if it is just an exercise...

Gary


> -Rob
>
> >
> > Gary
> >
> > On Wed, Aug 22, 2018 at 7:04 AM Rob Tompkins <chtompki@xxxxxxxxx> wrote:
> >
> >> Seems reasonable. Should we go with 2.0?
> >>
> >> -Rob
> >>
> >>> On Aug 22, 2018, at 6:35 AM, Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx>
> >> wrote:
> >>>
> >>> On Tue, 21 Aug 2018 22:04:12 -0400, Rob Tompkins wrote:
> >>>> I’m curious to gauge what people think here. My general thought is no
> >>>> breaking BC without a major version change. So, even though this is an
> >>>> internal component, we stick with the rules because we never know who
> >>>> else might be using the component, right?
> >>>
> >>> What potential BC breaking do you refer to?
> >>>
> >>> Anyways, if something needs fixing in code used internally and
> >>> the clean fix would require breaking compatibility, why not
> >>> change to a new major version?
> >>>
> >>> Gilles
> >>>
> >>>>
> >>>> -Rob
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> >>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> >> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>
>