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
<gil...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
