You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2007/06/13 08:19:07 UTC
[all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
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 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 means that the [cli] release with the current changes would need to be 2.0.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI
1.1
Posted by Gary Gregory <gg...@seagullsoftware.com>.
+1, I would also like to see commons project releases say with each release if they adhere to this charter (as an extra checks and balances thing)
Thank you,
Gary
> -----Original Message-----
> From: Phil Steitz [mailto:phil.steitz@gmail.com]
> Sent: Tuesday, June 12, 2007 11:19 PM
> To: Jakarta Commons Developers List
> Subject: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
>
> 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 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 means that the [cli] release with the current changes would need to be 2.0.
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
Posted by Joerg Heinicke <jo...@gmx.de>.
Phil Steitz <phil.steitz <at> gmail.com> writes:
> a) no source, binary or semantic incompatibilities or deprecations
> introduced in a x.y.z release
I really wonder what's the problem with deprecations since they don't have any
influence on compatibility. I'd guess there is always a reason for deprecating
something. Not doing so despite that reason is most careless IMO since you
encourage users to use that commons' code despite knowing better that it is a
bad choice regarding future compatibility of the user's code.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
Posted by Joerg Heinicke <jo...@gmx.de>.
Rahul Akolkar <rahul.akolkar <at> gmail.com> writes:
> We still do:
>
> http://jakarta.apache.org/commons/releases/versioning.html
Regarding deprecation: It is considered a fully compatible change. So you can
actually deprecate at any point and don't need to postpone it a next release of
a particular type.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
Posted by Rahul Akolkar <ra...@gmail.com>.
On 6/13/07, Phil Steitz <ph...@gmail.com> 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).
<snip/>
We still do:
http://jakarta.apache.org/commons/releases/versioning.html
-Rahul
> 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 means that the [cli] release with the current changes would need to be 2.0.
>
> Phil
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org