Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 209.85.220.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F0C6B34.7050108@gmx.at>
References: <4F0C6B34.7050108@gmx.at>
Date: Tue, 10 Jan 2012 18:19:27 +0000
Message-ID: 
 <CAOGo0VYGtaEW4NVof=97ndkRoJf+AGiOjkm6gZ8BO0Xm=09tEA@mail.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
From: sebb <sebbaz@gmail.com>
To: Commons Developers List <dev@commons.apache.org>, sgoeschl@gmx.at
Content-Type: text/plain; charset=ISO-8859-1

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