git.net

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

Re: [release-plugin] Preparing for 1.4.


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?

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
>
>