So you're saying that the formula is to drop the "2.6" and place
a period between the first and sedond digits of what's currently the
release number? OK, I hadn't interpreted it that way. Does the sequence
continue like this?
... 9.9.0, 10.0.0, ...
And the underlying problem is that there are only so many
small numbers. Eventually, inevitably, constant bits accumulate in
front of the changing bits.
Given the three criteria shown above, Linus' proposed scheme:
yyyy.r.s
seems best to me. We know the year, it relates directly to common
experience and effectively is a small number (this year, last year,
two years ago... 0, 1, 2 years ago).
There's the potential for cognitive dissonance if the linux
kernel takes a yyy.x format and the distrbutions also use yyyy.x, but
the two aren't the same? e.g., what will people think if, say,
openSUSE 2009.2 contains linux kernel 2009.1? Perhaps the
distibutions would synchronize to kernel releases as a consequence of
a revised kernel naming convention?
There's the question of what to do if you plan on a end-of year
release, and it just doesn't happen. I see three strategies, some of
which have been mentioned already in this thread:
1) Retain the "yyyy.r" part, even though it's year yyyy+1 before the
stable relese is issued.
2008.3.rc5, 2008.3.rc6, [year 2009 arrives], 2008.3.rc7, 2008.3.0
2) Drop the "yyyy.r" and start over with rc1 for "yyyy+1.1".
2008.3.rc5, 2008.3.rc6, [year 2009 arrives], 2009.1.rc1, 2009.1.0
3) Drop the "yyyy.r" in favor of "yyyy+1.1", but don't break the
rc# numbering:
2008.3.rc5, 2008.3.rc6, [year 2009 arrives], 2009.1.rc7, 2009.1.0
The last varient seems strange on the surface, but I think it
would be easier in practice, because developers could refer to "rc5",
"rc6", "rc7", dropping the locally-constant bits will less potential
ambiguity than if the "rc#" sequence was interrupted.
Craig Milo Rogers
--
