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
