commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@btopenworld.com>
Subject Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
Date Wed, 13 Jun 2007 12:01:07 GMT
----- Original Message ----
From: Phil Steitz <phil.steitz@gmail.com>
> I would like very much for us to agree
> once and for all on some versioning/deprecation rules.
Exactly the thread I was about to start :-)

> 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).  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 http://apr.apache.org/versioning.html.
> 
> 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 is pretty much my thinking, except that I want to tighten 1c - 
"no removals without prior deprecations allowed in x.0 releases. Source and binary backward
incompatible changes may be considered at the edges of the API, but not the core."

(We have to be strict as many, many other open source projects rely on commons, and they can't
be re-compiled just because of commons. Commons has to act and behave close to the JDK on
incompatibilities).

Commons needs clarity on this subject, and having it should speed up releases and voting.

Stephen





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


Mime
View raw message