On 23 May 2017 at 16:22, Matt Sicker <boa...@gmail.com> wrote: > 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.
If the version of Lang is tied to Java, then surely there can only be one version used at a time? > 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> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
