commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
Date Wed, 13 Jun 2007 14:22:11 GMT
On 6/13/07, Phil Steitz <> wrote:
> Sorry, but I have to agree with Niall on this - needs to be 2.0 with
> the incompatible changes -  and I would like very much for us to agree
> once and for all on some versioning/deprecation rules.  We seem to
> have lost the old versioning guidelines (unless I am senile, we used
> to have these on the commons or Jakarta pages somewhere).

We still do:


>  Apart from
> 0), which is a conservative but worth-considering-carefully PoV, the
> rules below are more or less what we have been adhering to over the
> last several years in commons and I would like to propose that we
> standardize on them.  If all are OK, I will gin up a versioning page.
> A very good one, which is pretty much a C version of what I am
> proposing below, is
> 0) Never break backward source or binary compatibility - i.e., when
> you need to, change the package name.
> 1) 0 is going to have to fail sometimes for practical reasons.  When
> it does, fall back to
> a) no source, binary or semantic incompatibilities or deprecations
> introduced in a x.y.z release
> b) no source or binary incompatibilities in an x.y release, but
> deprecations and semantic changes allowed
> c) no removals without prior deprecations, but these and other
> backward incompatible changes allowed in x.0 releases.
> This means that the [cli] release with the current changes would need to be 2.0.
> Phil

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message