commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <>
Subject Re: [ALL] About binary compatibility
Date Sun, 05 Jun 2016 15:58:09 GMT
Hello Oilver,

Oliver Heger <> 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,

> My $0.02
> Oliver
> >
> > Benedikt
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message