commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@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 13:09:02 GMT
On 13 January 2012 06:00, Henri Yandell <flamefew@gmail.com> wrote:
> 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.

What do you mean by bad packaging?

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

Given that the reason for breaking binary compat. in this example is
that we got the API wrong originally, it seems very unfair to choose
to fix the problem in a way that causes a potentially insoluble
problem for classpaths with multiple dependencies on the component.

Especially since there is an alternative that avoids the problem.
In both cases the producers of jars that depend on our component are
going to have to recompile and re-release in order to use the updated
API.
There is an additional cost of editting the source to allow for the
renamed method/class/package, but compared with
recompiling/re-releasing it seems to me that is a relatively small
additional cost.


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