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. I will note that the JDK is removing methods due to exactly the same issue - modular Java is quite disruptive.. 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 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". Options that remove the methods: 3) Make a backwards incompatible change to remove the bad methods in v3.7 (no package name change) 4) Make a backwards incompatible change to remove the bad methods in v4.0 (no package name change) 5) Make a backwards incompatible change to remove the bad methods in v4.0 (with package name change) 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
