[release-plugin] Preparing for 1.4.

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[release-plugin] Preparing for 1.4.

Rob Tompkins
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?

-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [release-plugin] Preparing for 1.4.

garydgregory
Well, BC is pretty binary... it seems simple to maintain BC. Javadoc,
deprecate, and keep BC IMO.

Gary

On Tue, Aug 21, 2018, 20:04 Rob Tompkins <[hidden email]> 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?
>
> -Rob
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [release-plugin] Preparing for 1.4.

Gilles Sadowski
In reply to this post by Rob Tompkins
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [release-plugin] Preparing for 1.4.

Rob Tompkins
Seems reasonable. Should we go with 2.0?

-Rob

> On Aug 22, 2018, at 6:35 AM, Gilles <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [release-plugin] Preparing for 1.4.

garydgregory
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 <[hidden email]> wrote:

> Seems reasonable. Should we go with 2.0?
>
> -Rob
>
> > On Aug 22, 2018, at 6:35 AM, Gilles <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [release-plugin] Preparing for 1.4.

Rob Tompkins


> On Aug 22, 2018, at 9:38 AM, Gary Gregory <[hidden email]> 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.

-Rob

>
> Gary
>
> On Wed, Aug 22, 2018 at 7:04 AM Rob Tompkins <[hidden email]> wrote:
>
>> Seems reasonable. Should we go with 2.0?
>>
>> -Rob
>>
>>> On Aug 22, 2018, at 6:35 AM, Gilles <[hidden email]>
>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [release-plugin] Preparing for 1.4.

garydgregory
On Wed, Aug 22, 2018 at 7:53 AM Rob Tompkins <[hidden email]> wrote:

>
>
> > On Aug 22, 2018, at 9:38 AM, Gary Gregory <[hidden email]>
> 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 <[hidden email]> wrote:
> >
> >> Seems reasonable. Should we go with 2.0?
> >>
> >> -Rob
> >>
> >>> On Aug 22, 2018, at 6:35 AM, Gilles <[hidden email]>
> >> 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: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [release-plugin] Preparing for 1.4.

sebb-2-2
On 22 August 2018 at 15:04, Gary Gregory <[hidden email]> wrote:

> On Wed, Aug 22, 2018 at 7:53 AM Rob Tompkins <[hidden email]> wrote:
>
>>
>>
>> > On Aug 22, 2018, at 9:38 AM, Gary Gregory <[hidden email]>
>> 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.

Would be strive to avoid breaking BC for internal packages?
I would hope not.

So I don't see why we should do so for internal components.

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

Breaking BC can cause unresolvable issues, but changing packages and
Maven coords causes extra work.

There is no perfect solution, so any 'rules' need to allow for pragmatism.

> Gary
>
>
>> -Rob
>>
>> >
>> > Gary
>> >
>> > On Wed, Aug 22, 2018 at 7:04 AM Rob Tompkins <[hidden email]> wrote:
>> >
>> >> Seems reasonable. Should we go with 2.0?
>> >>
>> >> -Rob
>> >>
>> >>> On Aug 22, 2018, at 6:35 AM, Gilles <[hidden email]>
>> >> 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: [hidden email]
>> >>> For additional commands, e-mail: [hidden email]
>> >>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [release-plugin] Preparing for 1.4.

Gilles Sadowski
On Wed, 22 Aug 2018 18:04:59 +0100, sebb wrote:

> On 22 August 2018 at 15:04, Gary Gregory <[hidden email]>
> wrote:
>> On Wed, Aug 22, 2018 at 7:53 AM Rob Tompkins <[hidden email]>
>> wrote:
>>
>>>
>>>
>>> > On Aug 22, 2018, at 9:38 AM, Gary Gregory
>>> <[hidden email]>
>>> 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.
>
> Would be strive to avoid breaking BC for internal packages?
> I would hope not.
>
> So I don't see why we should do so for internal components.
>
>>>
>>
>> OK, then let's play by our rules even if it is just an exercise...
>
> Breaking BC can cause unresolvable issues, but changing packages and
> Maven coords causes extra work.
>
> There is no perfect solution, so any 'rules' need to allow for
> pragmatism.

Unfortunately, "pragmatism" is not viewed the same way by everyone.
Cf. the recent (non-)discussion about breaking BC of "Commons RNG":
in all likelihood, it would not cause any problem; so, pragmatically
(IMHO)...

Regards,
Gilles

>> Gary
>>
>>
>>> -Rob
>>>
>>> >
>>> > Gary
>>> >
>>> > On Wed, Aug 22, 2018 at 7:04 AM Rob Tompkins <[hidden email]>
>>> wrote:
>>> >
>>> >> Seems reasonable. Should we go with 2.0?
>>> >>
>>> >> -Rob
>>> >>
>>> >>> On Aug 22, 2018, at 6:35 AM, Gilles
>>> <[hidden email]>
>>> >> 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: [hidden email]
For additional commands, e-mail: [hidden email]