commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@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 Thu, 12 Jan 2012 08:27:38 GMT
On Tue, Jan 10, 2012 at 10:19 AM, sebb <sebbaz@gmail.com> wrote:
> On 10 January 2012 16:45, 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.
>
> If the jar is not a drop-in replacement for the previous version, then
> yes, IMO that requires a major release. [1]
> The only possible exception might be if the incompatibilities are in
> internal parts of the API, i.e. classes/methods etc. that are not used
> externally.

Thinking back on previous discussions, the primary exception has been
the API itself is the bug and needs changing.

A contrived (and over-simple) example would be:

    public void toUppercase(String s);

It'd be better to fix the return type than live with bad API.

Rare, but worth mentioning I thought.

Hen

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


Mime
View raw message