That's a reasonable style of versioning :) I had many issues with binary compatibilty with a commons-email release due to changing the return value from void to a this reference plus some moving of constants. You basically end up with either many restrictions or creating major releases
Cheers, Siegfried Goeschl > Am 08.10.2013 um 12:40 schrieb Torsten Curdt <tcu...@vafer.org>: > > Cannot remember which component from the top of my head - but it was > related to package name changes. > > My style of thinking: x.y.z > > x - no compatibility > y - source compatibility > z - binary compatibility > > is simple and makes sense. > > It's OK to put some burden on the users when upgrading - as long as the > expectations are set correctly. > But I am pretty sure we discussed that before and some people did not agree. > > cheers, > Torsten > > >> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bode...@apache.org> wrote: >> >>> On 2013-10-08, Emmanuel Bourg wrote: >>> >>> Le 07/10/2013 20:14, Benedikt Ritter a écrit : >> >>>> - loosen API compatibility policy? >> >>> This topic alone deserves its own thread I think. >> >>> Ensuring binary/source compatibility is very important. >> >> +1 >> >> I guess I've done too much ruby with "every bundle update runs the risk >> of breaking everything" lately. I really value the stability commons >> provides. >> >> That being said, I'm sure there are cases where our policy seems >> stricter than it needs to be - even though I haven't seen a really >> difficult case in the one component I contribute to. >> >> Stefan >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org