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
