commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [ALL] About binary compatibility
Date Thu, 02 Jun 2016 20:54:44 GMT

Unhappy with it but agreeing that your definition sounds like it should apply.

I would vote for always bumping at least the minor version when requiring newer dependencies
(including Java Version). Strictly speaking semver would require a major version but with
our policy of using new package names for major versions that would annoy lots of users.

And we really really need to avoid VFS-style release congestions (because backporting becomes
prohibitively painful).



-----Original Message-----
From: Benedikt Ritter <>
To: Commons Developers List <>
Sent: Do., 02 Juni 2016 22:43
Subject: [ALL] About binary compatibility


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

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message