On March 28, 2007 4:35:50 PM -0400 John Peacock <[EMAIL PROTECTED]> wrote:
What this model does is to make many more small releases (no more RC129),
each with a stable feature set.
I don't see how that's different than a/b/rc numbering. You can still
cut as many releases as you like.
1.1.0
1.2.0b1
1.2.0b2
1.2.0rc1
1.1.1
1.2.0rc2
1.2.0rc3
1.2.0
And of course concurrently you can have 2.0{a,b,rc}.
The highest even numbered release is
always the "best choice"
With a/b/rc the highest numbered release (period, without having to
distinguish between even/odd) without a letter suffix is always
the "best choice".
and there is never any feature in an even
numbered release that wasn't developed in the preceding odd-numbered dev
branch.
I also don't see how that's different than a/b/rc numbering. There would
never be a feature in (say) 1.1.1 that wasn't developed in some other
branch.
For reference purposes, see how Apache project handles versions:
http://apr.apache.org/versioning.html
Although this doesn't hew to the even/odd model, it is still about as
air-tight a scheme as is possible with OSS.
That doesn't describe how features from development versions propagate
to release versions. Or even how development versions are numbered.
Otherwise, thanks for the link. I do like that doc.
From the discussion here, the only difference I can see lies in what is
the "best" version. With even/odd, it's always the highest numbered
even release. With a/b/rc, it's always the highest numbered numeric
release.
-frank
