Hi Gary, A new major release requires a new package name, site, build and so on - think of commons-lang v1,2,3
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
