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