Hello, 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). Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Benedikt Ritter <brit...@apache.org> To: Commons Developers List <dev@commons.apache.org> Sent: Do., 02 Juni 2016 22:43 Subject: [ALL] About binary compatibility 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? Benedikt --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
