Hello Oilver, Oliver Heger <oliver.he...@oliver-heger.de> schrieb am So., 5. Juni 2016 um 16:46 Uhr:
> 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. > Nevertheless I think we should document this. I'm tired of "why can't we implement this in a Java 6 compatible way" arguments. Java 6 is dead and Java 7 soon will be. There is no reason for us to support Java versions which not even Oracle supports anymore. > > 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. > I agree with you on this. > > 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. > We have done this in the past for BeanUtils2 in the sandbox. I don't think experiments should be forked into the sandbox. My feeling is, that those experiments get less attention. Speaking about [lang]: I discussed a redesign with Henri a year ago. The only problem I see is the time constraint. [lang] is a pretty large code base (~29k LoC) and I fear the that I won't be able the bring the redesign to an end. If others like to push that, I'm all for that. > > 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. > Again I agree. Thank you, Benedikt > > My $0.02 > Oliver > > > > > Benedikt > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
