On 9 October 2013 05:14, Siegfried Goeschl <siegfried.goes...@it20one.at> wrote: > Hi Gary, > > A new major release requires a new package name, site, build and so on - > think of commons-lang v1,2,3
Huh? A major release does not imply an API break, though the reverse is true. > Cheers, > > Siegfried Goeschl > >> Am 08.10.2013 um 22:54 schrieb Gary Gregory <garydgreg...@gmail.com>: >> >> 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 >> > > --------------------------------------------------------------------- > 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
