The goal is to level set, so that we don't run into this stuff. On Tue, Oct 8, 2013 at 9:27 AM, Phil Steitz <phil.ste...@gmail.com> wrote: > > >> On Oct 8, 2013, at 5:52 AM, James Carman <ja...@carmanconsulting.com> wrote: >> >> However, code modifications can be vetoed and nobody can overrule the veto. >> > Honestly, I have not seen that much, other Sw What we need IMO is less talk > and more code. Nobody has "blocked" or "vetoed" any new work on major > release versions. What has been lacking is critical mass to really > collaborate on the new stuff and fix bugs in the stuff that has been > released. There are infinitely many natural numbers to work with. Just > change package name, start a branch and go. We should all realize of course > that if our APIs are too unstable and we don't back port bug fixes because > all we want to do is "innovate" people won't really use our stuff. > >>> 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 >> > > --------------------------------------------------------------------- > 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
