On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl <siegfried.goes...@it20one.at> wrote: > 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
Then just create major releases! ;) Why would you not want to provide BC? Why add to the jar hell problem? I, the developer, have no control over how the API I provide will be used and distributed... G > > 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 > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
