commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [release-plugin] Preparing for 1.4.
Date Wed, 22 Aug 2018 17:18:06 GMT
On Wed, 22 Aug 2018 18:04:59 +0100, sebb wrote:
> On 22 August 2018 at 15:04, Gary Gregory <garydgregory@gmail.com> 
> wrote:
>> On Wed, Aug 22, 2018 at 7:53 AM Rob Tompkins <chtompki@gmail.com> 
>> wrote:
>>
>>>
>>>
>>> > On Aug 22, 2018, at 9:38 AM, Gary Gregory 
>>> <garydgregory@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.
>
> 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 <chtompki@gmail.com>

>>> wrote:
>>> >
>>> >> Seems reasonable. Should we go with 2.0?
>>> >>
>>> >> -Rob
>>> >>
>>> >>> On Aug 22, 2018, at 6:35 AM, Gilles 
>>> <gilles@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message