You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gilles (JIRA)" <ji...@apache.org> on 2018/01/11 14:22:00 UTC
[jira] [Updated] (RNG-46) Benign incompatibility (?)
[ https://issues.apache.org/jira/browse/RNG-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gilles updated RNG-46:
----------------------
Summary: Benign incompatibility (?) (was: Benign binary incompatibility (?))
> Benign incompatibility (?)
> --------------------------
>
> Key: RNG-46
> URL: https://issues.apache.org/jira/browse/RNG-46
> Project: Commons RNG
> Issue Type: Bug
> Reporter: Gilles
> Priority: Blocker
> Labels: compatibility, incompatibility
> Fix For: 1.1
>
>
> Clirr reports this error:
> {{Removed org.apache.commons.rng.sampling.distribution.SamplerBase from the list of superclasses}}
> for this class:
> {{org.apache.commons.rng.sampling.distribution.BoxMullerLogNormalSampler}}
> It is quite true.
> However, no functionality inherited from {{SamplerBase}} could have been used since a {{null}} was passed to its constructor (i.e. any call to a method from the base class would trigger a {{NullPointerException}}).
> Moreover:
> * {{SamplerBase}} is only meant for internal usage,
> * it only contains {{protected}} methods,
> * {{BoxMullerLogNormalSampler}} is going to be flagged as {{@deprecated}} in the next release.
> Hence, I think that it is quite safe to release a 1.1 version (i.e. no change in major number!) despite this incompatibility.
> Please confirm.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
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
>
>
[RNG][All] Benign incompatibility (?)
Posted by Gilles <gi...@harfang.homelinux.org>.
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