Your proposal, much like gstein's, is flawed because it conflates
"unstable release off the trunk" with "not-yet-vetted release off a
release branch."
On Fri, 2003-12-12 at 16:07, kfogel@collab.net wrote:
> Also, many have commented that one problem with using words in a
> release number is that you don't know whether the word is leading to
> the current number, or the next number. E.g., is the series
> "1.1.1-unstable", "1.1.2-unstable", and so on, leading to "1.2.0", or
> to "1.1"?
This is clearer with "1.1.beta1", precisely because "beta" is very
different from "unstable." But we have other reasons not to like that
scheme, so, moving on:
> Let's use "odd==unstable,even=stable" in the minor numbers, but with
> an "unstable-" *prefix* on all the odd-numbered releases. That way,
> users don't need to know about the even/odd thing. The unstable
> releases will always be clearly marked as unstable.
The problem comes when we branch for the next stable release (1.2, in
your proposal). Now we have to differentiate between beta releases of
1.2 and unstable releases on the trunk which happen to chronologically
predate the release of 1.2. The even/odd scheme works against us; we
could wind up with confusing release orders like:
subversion-unstable-1.1.1
subversion-unstable-1.1.2
<branch point for 1.2>
subversion-unstable-1.1.3 from branch
subversion-unstable-1.3.0 from trunk
subversion-unstable-1.1.4 from branch
subversion-unstable-1.3.1 from trunk
subversion-1.2.0 from branch
By using odd/even, you are trying to linearize a fundamentally
non-linear structure of releases, and the result is confusion. This is
why Linux winds up with version numbers like 1.2.0-pre6 even though it
uses odd/even.
So, let me counterpropose:
Stable releases are named subversion-x.y.z, no odd/even
Not-yet-vetted branch releases are named subversion-beta-x.y-rXXXXX
(or subversion-alpha-x.y-rXXXXX if we feel they're of alpha quality)
Snapshots off the trunk are named subversion-snapshot-rXXXXX
We discourage binary packaging of anything other than stable releases
So, we get:
subversion-snapshot-r10135 from trunk
subversion-snapshot-r10242 from trunk
<branch point for 1.1>
subversion-beta-1.1-r10321 from branch
subversion-snapshot-r10400 from trunk
subversion-beta-1.1-r10412 from branch
subversion-1.1.0 from branch
I like this because:
* Stable releases live in a different version space from everything
else, and that version space reflects the branch structure which exists
for them. Odd/even would be a distortion of the branch structure.
* It's easy to identify where unstable releases came from in the
repository, and what they are.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 13 15:54:40 2003