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 Fri, 13 Jan 2012 06:00:35 GMT
On Thu, Jan 12, 2012 at 2:52 AM, sebb <sebbaz@gmail.com> wrote:
> On 12 January 2012 08:27, Henri Yandell <flamefew@gmail.com> wrote:
>> 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.
>
> But that can still cause jar hell.
>
> If there are multiple jars in the same classloader that use the broken
> API, they will all have to be updated at the same time.
> May be tricky or impossible even if they are not from different providers.
>
> That's why binary compatibility is so important.

Bad packaging practices causes jar hell. There's only so far we can go
worrying about how our code is used.

Part of the reason I felt it worth mentioning is that binary
compatibility is not a magic trump card that aces everything else.
It's very strongly desirable but not a mandatory absolute.

Hen

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


Mime
View raw message