However, code modifications can be vetoed and nobody can overrule the veto.
On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > On Tue, Oct 8, 2013 at 8:38 AM, James Carman > <ja...@carmanconsulting.com>wrote: > >> Yes, we know we're allowed to do that, but folks seem to fight against >> moving forward. >> > > All you need is a [VOTE] and be done with it. > > Gary > > >> >> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <garydgreg...@gmail.com> >> wrote: >> > You can break BC all you want when you do it in a NEW package. For >> > example lang3. >> > >> > Gary >> > >> > On Oct 8, 2013, at 6:41, Torsten Curdt <tcu...@vafer.org> wrote: >> > >> >> 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 >> > >> >> --------------------------------------------------------------------- >> 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<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > 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
