On Tue, Jan 10, 2012 at 10:19 AM, sebb <seb...@gmail.com> wrote:
> On 10 January 2012 16:45, Siegfried Goeschl <sgoes...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
