commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [DISCUSS] API compatibility policy
Date Tue, 08 Oct 2013 10:48:26 GMT
I think the idea is to change the mindset.  There seems to be an almost
militant desire to maintain compatibility.  Yes, we have the version number
scheme, but some folks just never want to break compatibility it seems.
 This stalls innovation.  I don't want to debate every change, so setting
the expectations up-front is a good idea.

On Tuesday, October 8, 2013, Torsten Curdt 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<javascript:;>>
> 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<javascript:;>
> > For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
> >
> >
>

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