> 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
