commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [ALL] About binary compatibility
Date Thu, 02 Jun 2016 21:05:26 GMT
On Thu, Jun 2, 2016 at 1:42 PM, Benedikt Ritter <> wrote:

> 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.

I would also be OK to actually bump the major release version of a
component when the Java plaform changes _without_ changing the package
name. This would just be a nice indication that something important have
changed that WILL break applications stuck on older JREs.

Nice email. You have beaten me to the punch!


> What is your view on the topic?
> Benedikt

E-Mail: |
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition <>
Spring Batch in Action <>

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