I think we should adopt Java 9’s multi-release jars [1] as standard practice. While this won’t let us update our APIs without breaking compatibility (which may still be necessary), it will allow us to leverage some features in newer versions of Java without worrying about breaking backward compatibility.
I also see no reason we can’t leave links on the web site to the last release that supported an older version of Java and have a branch for further work if anyone wants to do it. In the end I think we have to have an approach where we can move forward and support the newer versions of Java more quickly while still continuing to be able to support older versions - if we choose to. As far as moving forward and breaking binary compatibility, I believe Oliver did a great job with Configuration 2.0. He first worked on an experimental branch and got it to the state where he could release it. Although I wish I could have contributed more to his efforts I think the way he went about it encouraged others to review what he was doing and participate if and when they wanted to. At the same time bugs in the older releases continued to be addressed. Ralph [1] http://openjdk.java.net/jeps/238 <http://openjdk.java.net/jeps/238> > On Jun 5, 2016, at 7:46 AM, Oliver Heger <oliver.he...@oliver-heger.de> wrote: > > Hi Benedikt, > > Am 02.06.2016 um 22:42 schrieb Benedikt Ritter: >> Hi, >> >> we do seem to have different opinions when it comes to binary compatibility >> and how it should be handled. Usually we would say "this should be decided >> on a component basis". However this discussion is coming up again and again >> and I think we should try the impossible and agree on something that we can >> document. >> >> So here is my view on the topic: >> >> - since our components are depended upon by a lot of projects, we need to >> take special care regarding compatibility. >> - we must not break BC in a release that could collide with an earlier >> version. In other words, when we break BC, we have to change package and >> maven coordinates. >> - BUT since we're all doing this on our spare time, there is no need to >> hold on old APIs just for the sake of it. For this reason, BC may be broken >> any time, if the steps above a followed and it has been discussed on the >> ML. Fixes can always be backported to old releases, by people who need it. >> - If there are committers who are willing to work on old version and >> committers who want to work on API redesigns, we can branch and work in >> paralell. >> - Changing the Java Language requirement does not break BC and can >> therefore be done without pumping the major version. >> >> What is your view on the topic? > > these points are rather technical ones, and most of us will probably > agree. The more important question is IMHO: when do we explicitly break > BC because we want to make use of new language features or switch to a > different design? In this area we used to be very conservative. > > Take BCEL as an example. There was a strong momentum about half a year > or so ago to push out a new major release breaking BC. Then discussion > started to revert breaking changes. This would of course have been the > ideal solution for all users: getting a new version without migration > effort. However, the result was that work on reverting changes started, > but was never finished. The momentum vanished, and the release is still > overdue. So would it has been better to break BC in this case? I tend to > say yes. > > Or let's discuss another component: [lang]. The last major release > happened about 5 years ago. In software business these are ages. So > would it make sense to start working on a new version focusing on Java 8 > and better support for Lambdas? We could at least start something in an > experimental branch or the sandbox to experiment with new functionality. > But it is obviously not our style to do this. > > It is certainly difficult to find the right balance between stability > and innovation. For our fundamental components it is for sure no good > idea to push out an incompatible major release every few months. But > every 3 or 4 years when there are significant changes in the Java > ecosystem would probably be okay. > > My $0.02 > Oliver > >> >> Benedikt >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
