commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [DISCUSS] API compatibility policy
Date Tue, 08 Oct 2013 12:49:11 GMT
On Tue, Oct 8, 2013 at 8:38 AM, James Carman <james@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 <garydgregory@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 <tcurdt@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 <bodewig@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-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message