commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <grobme...@gmail.com>
Subject Re: When to create a new major release - Was [VOTE][CANCEL] The vote for commons-email-1.3 based on RC2 in cancelled
Date Tue, 10 Jan 2012 20:04:30 GMT
On Tue, Jan 10, 2012 at 8:54 PM, sebb <sebbaz@gmail.com> wrote:
> On 10 January 2012 19:37, Christian Grobmeier <grobmeier@gmail.com> wrote:
>> On Tue, Jan 10, 2012 at 5:45 PM, Siegfried Goeschl <sgoeschl@gmx.at> wrote:
>>> Hi folks,
>>>
>>> the main reason for the failed vote of commons-email-1.3 is that the release
>>> is only source but not binary compatible
>>>
>>> +) if you compile your application with the new version everything is fine
>>> +) if you replace simply the JAR the invocation fails
>>>
>>> Is it mandatory that a minor release is binary compatible with the previous
>>> one or do I have to create a new major version? There is a lot of ugly stuff
>>> (mainly protected member variables) which should be done but is currently
>>> not in the scope of this release.
>>>
>>> Feedback appreciated
>>
>> "Developers must perform a major release whenever the new release is
>> not at least interface-compatible with the previous release."
>> http://commons.apache.org/releases/versioning.html
>>
>> In my opinion if you just add something, you don't need to increment.
>
> Depends what you add.
> If you add a method to an interface, that is binary compatible, but
> not source compatible.

guidelines say, this is ok with a minor increment:

Examples of interface-compatible changes include:

- all fully-compatible changes
- changing a component such that it now depends upon an additional
external library or configuration file

Examples of changes which are not interface-compatible include:
- changing a public or protected method signature
- changing the default value of an attribute in a behaviour changing way
- removing a class, interface, method or attribute from either the
internal or external interface of the component

The list is pretty concrete.
It does not say anything on binary compatibility (or i didn't find it).

Cheers,
Christian

>
>> If you take something away, you should increment.
>
> Again, depends what you remove.
> But in general that will cause both binary and source incompatibilities.
>
>> See also the section "Fully-Compatible Changes"
>>
>> Btw, I like this very much: http://semver.org/.
>> "Major version X (X.y.z | X > 0) MUST be incremented if any backwards
>> incompatible changes are introduced to the public API"
>
> Agreed.
>
> I think the Commons guidelines are very close to that.
>
>> Cheers
>> Christian
>>
>>>
>>> Siegfried Goeschl
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>>
>> ---------------------------------------------------------------------
>> 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
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

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


Mime
View raw message