commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siegfried Goeschl <sgoes...@gmx.at>
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 Wed, 11 Jan 2012 07:16:22 GMT
Hi folks,

I think the best for commons-email-1.3 will be reverting the changes of 
the setters from

Email setXXX(arg)

to

void setXXX(arg)

which in turn gives me binary backward compatibility. I would like to 
see a commons-email-1.3 out there which gives me time to work on 2.0

Cheers,

Siegfried Goeschl


On 10.01.12 19:19, sebb 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.
>
> Note also that a binary incompatibility involving the external API
> will also require the package name to be changed (which in turn
> requires the Maven coordinates to be changed).
>
> The package name change is required because there can be only one
> instance of a class in a single class loader.
> See discussion here [2]
>
> [1] http://commons.apache.org/releases/versioning.html
> [2] http://wiki.apache.org/commons/MavenGroupIDChange#Classpath_considerations
>> Feedback appreciated
>>
>> Siegfried Goeschl
>>
>> ---------------------------------------------------------------------
>> 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