You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles <gi...@harfang.homelinux.org> on 2018/01/15 12:13:18 UTC
[RNG][All] Benign incompatibility (?)
Hi.
Please have a look at this issue on JIRA:
https://issues.apache.org/jira/browse/RNG-46
and confirm that a release won't be blocked by the
current "clirr" report.
Thanks,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG][All] Benign incompatibility (?)
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 24 Jan 2018 21:30:21 +0100, Oliver Heger wrote:
> Am 24.01.2018 um 14:29 schrieb Gilles:
>> Ping?
>>
>> More opinions, please (to avoid rehashing the issue at
>> vote time).
>>
>> Thanks,
>> Gilles
>>
>> On Mon, 15 Jan 2018 22:14:03 +0100, Gilles wrote:
>>> On Mon, 15 Jan 2018 09:49:44 -0700, Gary Gregory wrote:
>>>> Hi All,
>>>>
>>>> There are some many ways this can create jar hell now and in the
>>>> future
>>>> that I would not want to risk it. Binary compatibility is
>>>> something we
>>>> should strive for IMO. If this change is _that_ important, then
>>>> it's 2.0
>>>> time. Otherwise, don't break application stacks. Especially since
>>>> Commons
>>>> components tend to live at the bottom of such stacks. I see plenty
>>>> of
>>>> stacks out there for example, that include _both_ [lang] and
>>>> [lang3],
>>>> and
>>>> that is _fine_.
>>>
>>> The point is that no correct application can be broken by this
>>> change.
>>> Rather the contrary, with the prospective v1.1, failure will happen
>>> at compile time (for incorrect application code that would have
>>> tried
>>> to call base class methods), while v1.0 will happily compile (and
>>> then
>>> raise a NPE).
>>> Furthermore, in both cases, correct usage (i.e. calling the
>>> "sample"
>>> method) will work the same, and as expected; no JAR hell
>>> whatsoever.
>>>
>>> The incompatible change is actually an improvement from a
>>> application
>>> developer's POV.
>
> A Clirr violation would be fine with me if it is addressed in the
> release notes,
Added in "changes.xml".
> and the probability of creating a jar hell scenario is
> rather low.
I'd think it is zero.
But no problem in reverting the change if someone comes
up with a scenario.
Thanks,
Gilles
> Oliver
>
>
>>>
>>> Gilles
>>>
>>>>
>>>> Gary
>>>>
>>>> On Mon, Jan 15, 2018 at 5:13 AM, Gilles
>>>> <gi...@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>>> Hi.
>>>>>
>>>>> Please have a look at this issue on JIRA:
>>>>> https://issues.apache.org/jira/browse/RNG-46
>>>>> and confirm that a release won't be blocked by the
>>>>> current "clirr" report.
>>>>>
>>>>> Thanks,
>>>>> Gilles
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG][All] Benign incompatibility (?)
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 24.01.2018 um 14:29 schrieb Gilles:
> Ping?
>
> More opinions, please (to avoid rehashing the issue at
> vote time).
>
> Thanks,
> Gilles
>
> On Mon, 15 Jan 2018 22:14:03 +0100, Gilles wrote:
>> On Mon, 15 Jan 2018 09:49:44 -0700, Gary Gregory wrote:
>>> Hi All,
>>>
>>> There are some many ways this can create jar hell now and in the future
>>> that I would not want to risk it. Binary compatibility is something we
>>> should strive for IMO. If this change is _that_ important, then it's 2.0
>>> time. Otherwise, don't break application stacks. Especially since
>>> Commons
>>> components tend to live at the bottom of such stacks. I see plenty of
>>> stacks out there for example, that include _both_ [lang] and [lang3],
>>> and
>>> that is _fine_.
>>
>> The point is that no correct application can be broken by this change.
>> Rather the contrary, with the prospective v1.1, failure will happen
>> at compile time (for incorrect application code that would have tried
>> to call base class methods), while v1.0 will happily compile (and then
>> raise a NPE).
>> Furthermore, in both cases, correct usage (i.e. calling the "sample"
>> method) will work the same, and as expected; no JAR hell whatsoever.
>>
>> The incompatible change is actually an improvement from a application
>> developer's POV.
A Clirr violation would be fine with me if it is addressed in the
release notes, and the probability of creating a jar hell scenario is
rather low.
Oliver
>>
>> Gilles
>>
>>>
>>> Gary
>>>
>>> On Mon, Jan 15, 2018 at 5:13 AM, Gilles <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>>> Hi.
>>>>
>>>> Please have a look at this issue on JIRA:
>>>> https://issues.apache.org/jira/browse/RNG-46
>>>> and confirm that a release won't be blocked by the
>>>> current "clirr" report.
>>>>
>>>> Thanks,
>>>> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG][All] Benign incompatibility (?)
Posted by Gilles <gi...@harfang.homelinux.org>.
Ping?
More opinions, please (to avoid rehashing the issue at
vote time).
Thanks,
Gilles
On Mon, 15 Jan 2018 22:14:03 +0100, Gilles wrote:
> On Mon, 15 Jan 2018 09:49:44 -0700, Gary Gregory wrote:
>> Hi All,
>>
>> There are some many ways this can create jar hell now and in the
>> future
>> that I would not want to risk it. Binary compatibility is something
>> we
>> should strive for IMO. If this change is _that_ important, then it's
>> 2.0
>> time. Otherwise, don't break application stacks. Especially since
>> Commons
>> components tend to live at the bottom of such stacks. I see plenty
>> of
>> stacks out there for example, that include _both_ [lang] and
>> [lang3], and
>> that is _fine_.
>
> The point is that no correct application can be broken by this
> change.
> Rather the contrary, with the prospective v1.1, failure will happen
> at compile time (for incorrect application code that would have tried
> to call base class methods), while v1.0 will happily compile (and
> then
> raise a NPE).
> Furthermore, in both cases, correct usage (i.e. calling the "sample"
> method) will work the same, and as expected; no JAR hell whatsoever.
>
> The incompatible change is actually an improvement from a application
> developer's POV.
>
> Gilles
>
>>
>> Gary
>>
>> On Mon, Jan 15, 2018 at 5:13 AM, Gilles
>> <gi...@harfang.homelinux.org>
>> wrote:
>>
>>> Hi.
>>>
>>> Please have a look at this issue on JIRA:
>>> https://issues.apache.org/jira/browse/RNG-46
>>> and confirm that a release won't be blocked by the
>>> current "clirr" report.
>>>
>>> Thanks,
>>> Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG][All] Benign incompatibility (?)
Posted by Gilles <gi...@harfang.homelinux.org>.
On Mon, 15 Jan 2018 09:49:44 -0700, Gary Gregory wrote:
> Hi All,
>
> There are some many ways this can create jar hell now and in the
> future
> that I would not want to risk it. Binary compatibility is something
> we
> should strive for IMO. If this change is _that_ important, then it's
> 2.0
> time. Otherwise, don't break application stacks. Especially since
> Commons
> components tend to live at the bottom of such stacks. I see plenty of
> stacks out there for example, that include _both_ [lang] and [lang3],
> and
> that is _fine_.
The point is that no correct application can be broken by this change.
Rather the contrary, with the prospective v1.1, failure will happen
at compile time (for incorrect application code that would have tried
to call base class methods), while v1.0 will happily compile (and then
raise a NPE).
Furthermore, in both cases, correct usage (i.e. calling the "sample"
method) will work the same, and as expected; no JAR hell whatsoever.
The incompatible change is actually an improvement from a application
developer's POV.
Gilles
>
> Gary
>
> On Mon, Jan 15, 2018 at 5:13 AM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> Hi.
>>
>> Please have a look at this issue on JIRA:
>> https://issues.apache.org/jira/browse/RNG-46
>> and confirm that a release won't be blocked by the
>> current "clirr" report.
>>
>> Thanks,
>> Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG][All] Benign incompatibility (?)
Posted by Gary Gregory <ga...@gmail.com>.
Hi All,
There are some many ways this can create jar hell now and in the future
that I would not want to risk it. Binary compatibility is something we
should strive for IMO. If this change is _that_ important, then it's 2.0
time. Otherwise, don't break application stacks. Especially since Commons
components tend to live at the bottom of such stacks. I see plenty of
stacks out there for example, that include _both_ [lang] and [lang3], and
that is _fine_.
Gary
On Mon, Jan 15, 2018 at 5:13 AM, Gilles <gi...@harfang.homelinux.org>
wrote:
> Hi.
>
> Please have a look at this issue on JIRA:
> https://issues.apache.org/jira/browse/RNG-46
> and confirm that a release won't be blocked by the
> current "clirr" report.
>
> Thanks,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>