On Wed, Aug 22, 2018 at 7:53 AM Rob Tompkins <chtom...@gmail.com> wrote:
> > > > On Aug 22, 2018, at 9:38 AM, Gary Gregory <garydgreg...@gmail.com> > 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 <chtom...@gmail.com> wrote: > > > >> Seems reasonable. Should we go with 2.0? > >> > >> -Rob > >> > >>> On Aug 22, 2018, at 6:35 AM, Gilles <gil...@harfang.homelinux.org> > >> 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-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
