+1 Stefan
On 2013-10-08, James Carman wrote: > Agreed. I think we should come up with a naming convention. The OSGi > community (the maven bundle plugin) has adopted the notion that any > package named "impl" or "internal" will not be exported. Perhaps we > set up that expectation to our users, too. If it's in a package named > as such, then it can change. Use at your own risk! > On Tue, Oct 8, 2013 at 9:35 AM, Phil Steitz <phil.ste...@gmail.com> wrote: >> Sorry, got away from me before I finished. By "other Sw" I meant "other than >> when someone wants to slip in a comparability break outside a major >> release." I agree with Luc that we should allow ourselves to designate parts >> of the API as "internal" so subject to change between major releases. For >> [math] at least that would be a big help. >> Sorry for the fat-fingering (again) >>> On Oct 8, 2013, at 6: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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
