On Wed, 22 Aug 2018 18:04:59 +0100, sebb wrote:
On 22 August 2018 at 15:04, Gary Gregory <garydgreg...@gmail.com>
wrote:
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.
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 <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
