A good resource if you didn't know it existed: http://commons.apache.org/releases/versioning.html
On Tue, Oct 8, 2013 at 3:54 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > 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 > > -- Cheers, Paul
