On March 28, 2007 4:35:50 PM -0400 John Peacock jpeacock@rowman.com 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