Tying versions of commons-lang to releases of Java itself makes a bit of sense to me, but then I do foresee projects containing like 5 different versions of commons-lang in the future which is somewhat annoying.
On 23 May 2017 at 10:07, sebb <seb...@gmail.com> wrote: > On 23 May 2017 at 12:18, Stephen Colebourne <scolebou...@joda.org> wrote: > > On 23 May 2017 at 11:54, sebb <seb...@gmail.com> wrote: > >>> Fixing it properly requires a major release, which implies that Lang > >>> 4.0 is still Java 1.7 and should use the `org.apache.commons.lang3` > >>> package name. > >> > >> I think that depends on whether the API is backwards-compatible or not. > >> > >> If it *is* backwards-compatible, then do we need a major release? > >> > >> If *not*, then 4.0 needs a new package. > >> > >> Why? > >> > >> Suppose code A depends on a LANG 3 method not present in 4 > >> and code B depends on some new feature in LANG 4 > >> > >> It's not possible to use A and B together on the same classpath. > >> > >> In which case 4.0 must use a new package and Maven coordinates. > > > > The change to remove PropertyChangeListener will be incompatible. > > Thus, if you want to be strict then you have to have a new package and > > maven co-ordinates. But IMO, this would simply cause end-user projects > > to have v2.x, v3.x and v4.x on the classpath - its bad enough with two > > versions right now, I don't personally think removing these two > > methods is enough to justify a new package/maven co-ordinate and the > > downstream mess that ensues. > > Huh? > > The whole point of changing the package name and Maven coords is to > allow mutually incompatible jars to coexist peacefully on a single > classpath. > > > > I will note that the JDK is removing methods due to exactly the same > > issue - modular Java is quite disruptive.. > > All the more reason not to cause additional unnecessary problems. > > > Options that leave the methods in: > > > > 1) Add module-info for v3.x that "requires java.desktop" and accept > > that end-users get Swing/AWT > > OK > > > 2) Add module-info for v3.x that "requires static java.desktop" (an > > optional dependency) and accept that users of circuit breaker must > > manually "require java.desktop". > > OK > > > Options that remove the methods: > > > > 3) Make a backwards incompatible change to remove the bad methods in > > v3.7 (no package name change) > > -1 > > This is a recipe for jar hell. > > > 4) Make a backwards incompatible change to remove the bad methods in > > v4.0 (no package name change) > > -1 > > This is a recipe for jar hell. > > > > > 5) Make a backwards incompatible change to remove the bad methods in > > v4.0 (with package name change) > > OK > > > If you do #4 or #5, you also need #1 or #2 for the v3.x branch. #3 is > > aggressive but gets rid of the issue in the fastest way. > > > > Stephen > > > > --------------------------------------------------------------------- > > 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 > > -- Matt Sicker <boa...@gmail.com>
