On Dec 4, 2003, at 2:19 PM, Branko Čibej wrote:
> Greg Hudson wrote:
>
>>> This is essentially the "even==stable, odd==dev" scheme that many
>>> other projects use.
>>>
>>>
>>
>> ... which is confusing as hell to the uninitiated. -0.9 on such a
>> numbering scheme.
>>
>>
> I agree, and add my -1. There are lots of other ways to tag an unstable
> version, two of which we're acquainted with:
>
> * Apache says x.y.z-dev *before* releasing x.y.z. (This is also
> GCC's way, I believe.)
This is not the same thing as having a maintenance track and a
development track. I present the APACHE_2_1_* dev branch as exhibit
#1.
> * BDB starts with x.y.0, making patch "releases" in between, then
> declares x.y.z as stable (e.g., the stable releases were 4.0.14,
> 4.1.25 and 4.2.50 -- not 4.0.0, 4.1.0 and 4.2.0)
>
> I prefer the Apache way, which means we release 1.0.0, then bump the
> trunk to 1.1.0-dev. Patch releases from the 1.0 branch would be 1.0.x.
> We can tag 1.1 prereleases with date stamps, e.g., tags/1.1.0-20040513,
> with "svn --version --quiet" saying "1.1.0-dev"
How is this different from what Karl is proposing aside from the fact
that you're not declaring the odd/even scheme? We're talking about
making an even-numbered release, which then becomes maintenance track,
and trunk continues as (odd-numbered) dev. Once dev on trunk
stabilizes and we're ready for release, then that becomes the next even
minor number, goes into maintenance, and dev continues on the next odd
minor number. It seems really simple to me. This looks like this:
.35 -> 1.0.0 rc
1.0.0 rc -> 1.0.0 maintenance, which is re-released as 1.0.1, 1.0.2
... 1.0.147, etc.
1.1.0 is born as a dev track, which becomes 1.1.x ... 1.1.793, etc
1.1.793 -> 1.2.0 rc
1.2.x rc -> 1.2.x maintenance, which is re-released as 1.2.x ...
1.2.237, etc.
1.3.0 is born as a dev track.....
1.3.x -> 1.4.0 rc
1.4.0 rc -> 1.4.x maint
Well, I like my bikeshed the same color as Karl's, so here's my +1 for
his stated even/odd numbering scheme (which I did discuss with him
prior to his sending the initial mail).
Normal users shouldn't ever even be aware of development (odd-numbered)
releases--I mean, when's the last time that you went and "accidentally"
grabbed a 2.5 release of the Linux kernel because you saw that 2.5.x is
higher than 2.4.x? And to address other issues, any package maintainer
worth his salt isn't going to blindly package up a dev release without
wrapping it in yellow-tape and concertina wire.
-Fitz, preparing for the flames of Čibej
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 5 00:08:32 2003