I think +0 for #1, +1 for #2, and +1 for (#4 or #5). -1 for #3 (though +1 for a 3.7 deprecating these methods).
For 4.0, I wonder if we could find a replacement for the property listeners from java.beans, or might be simpler just remove the property listeners, and have a simple interface for specifying the possible life cycle of a circuit breaker (similar to what Elastic Search does). I believe I was possibly responsible for introducing it in [lang], so happy to prepare as many development cycles as necessary to help sorting this out, and perhaps stepping up as a release manager for the first time to prepare some releases of lang. Cheers Bruno________________________________ From: Stephen Colebourne <scolebou...@joda.org> To: Commons Developers List <dev@commons.apache.org> Sent: Tuesday, 23 May 2017 11:18 PM Subject: Re: [LANG] Thoughts about Lang 4.0 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
