[RNG][All] Benign incompatibility (?)

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

[RNG][All] Benign incompatibility (?)

Gilles Sadowski
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG][All] Benign incompatibility (?)

garydgregory
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 <[hidden email]>
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [RNG][All] Benign incompatibility (?)

Gilles Sadowski
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
> <[hidden email]>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG][All] Benign incompatibility (?)

Gilles Sadowski
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
>> <[hidden email]>
>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG][All] Benign incompatibility (?)

Oliver Heger-3


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 <[hidden email]>
>>> 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: [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: [RNG][All] Benign incompatibility (?)

Gilles Sadowski
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
>>>> <[hidden email]>
>>>> 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: [hidden email]
For additional commands, e-mail: [hidden email]