commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [ALL] About binary compatibility
Date Thu, 02 Jun 2016 22:09:58 GMT
On Thu, Jun 2, 2016 at 2:26 PM, Emmanuel Bourg <ebourg@apache.org> wrote:

> Le 2/06/2016 à 22:42, Benedikt Ritter a écrit :
>
> > - since our components are depended upon by a lot of projects, we need to
> > take special care regarding compatibility.
>
> +1, thanks God Apache Commons isn't like Guava or BouncyCastle.
>
>
> > - we must not break BC in a release that could collide with an earlier
> > version. In other words, when we break BC, we have to change package and
> > maven coordinates.
>
> I tend to agree but I think some exceptions should be allowed:
> * If the element affected by the BC issue was released very recently, we
> should be able to roll out a new release changing it. For example if foo
> 1.3 added a protected method to a class, we should be able to make it
> private in foo 1.3.1 if we release it shortly after (let's say less than
> 2 months after foo 1.3).
>
-1

Timing is irrelevant. You cannot control what will end up in an app stack.
Once released, that's it unfortunately, otherwise, the door to jar hell is
open.

Gary


> * If the API affected is just internal stuff not intended to be used
> directly, it should be possible to change it.
>
>
> > - BUT since we're all doing this on our spare time, there is no need to
> > hold on old APIs just for the sake of it. For this reason, BC may be
> broken
> > any time, if the steps above a followed and it has been discussed on the
> > ML. Fixes can always be backported to old releases, by people who need
> it.
>
> Ok but this can only work if our release process is simplified, because
> backporting means publishing more releases
>
>
> > - Changing the Java Language requirement does not break BC and can
> > therefore be done without pumping the major version.
>
> I agree, bumping the major version isn't mandatory in this case.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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