commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [ALL] About binary compatibility
Date Fri, 03 Jun 2016 14:45:24 GMT
On Thu, 02 Jun 2016 21:35:45 +0000, Benedikt Ritter wrote:
> Emmanuel Bourg <ebourg@apache.org> schrieb am Do., 2. Juni 2016 um
> 23:26 Uhr:
>
>> 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).
>> * 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
>>
>
> Great idea! Let's start a discussion about our release process right 
> after
> we have settled an agreement about the BC topic.

[For the release process.]
I suggest people examine this document (in the "develop" branch of the
"math" repository):
   doc/release/release.howto.txt

Regards,
Gilles

>
>
>>
>>
>> > - 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
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message