commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
Date Wed, 13 Jun 2007 06:19:07 GMT
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).  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.


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

View raw message