In the case of BCEL, the coding actually stalled on fixing some bugs which were proving both difficult to test and fix.
The code that was reverted to become BC was largely orthogonal to that. On 5 June 2016 at 16:58, Benedikt Ritter <brit...@apache.org> wrote: > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
