commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [ALL] About binary compatibility
Date Fri, 03 Jun 2016 08:38:29 GMT
On 2 June 2016 at 21:42, 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.

+1, with the proviso that we must not break BC in the *public* API.
Unfortunately it is not always clear what is public.

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

I don't see why being a volunteer makes breaking BC more acceptable.
Remember that many of the consumers of the components will also be
volunteers (not least in other ASF projects) who will have to deal
with the consequences.

We should remember that there are generally many more consumers of the
components than there are developers.
So a small change is multiplied by a large number of people who need
to do the work.

If BC can be maintained by a developer spending a bit more time on the
code, that seems to me to be a worthy goal.

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

Versioning is largely separate from BC.

But again, Java upgrades can affect downstream consumers, so care must
be taken not to exclude too many potential users.

> What is your view on the topic?

Note that the above concerns depend to some extent on which component
is involved.
The lower-level components and popular dependencies (LANG, IO, NET
etc) need to be more careful about breaking changes.
Components such as MATH and IMAGING are less likely to be deep in a
dependency chain, so API/Java changes will likely affect fewer

> Benedikt

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

View raw message