On 2 June 2016 at 21:42, Benedikt Ritter <brit...@apache.org> 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.
+1 > - 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 consumers. > Benedikt --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
