Re: From 2.4 to 2.6 to 2.7?

["Rafael C. de Almeida" <almeidaraf@gmail.com>]

Willy Tarreau wrote:
> On Mon, Jul 14, 2008 at 08:55:59PM -0700, david@lang.hm wrote:
>> On Mon, 14 Jul 2008, Linus Torvalds wrote:
>>
>>>> Does it have to be even numbers only?
>>> No. But the even/odd thing is still so fresh in peoples memory (despite us
>>> not having used it for years), and I think some projects aped us on it, so
>>> if I didn't change the numbering setup, but just wanted to reset the minor
>>> number, I'd probably jump from 2.6 to 2.8 just for historical reasons.
>>>
>>> But I could also see the second number as being the "year", and 2008 would
>>> get 2.8, and then next year I'd make the first release of 2009 be 2.9.1
>>> (and probably avoid the ".0" just because it again has the connotations of
>>> a "big new untested release", which is not true in a date-based numbering
>>> scheme). And then 2010 would be 3.0.1 etc..
>> Ok, I'll jump in.
>>
>> I don't have strong feelings either, but I do have comments
>>
>> 1. for the historical reasons you allude to above going to a completely 
>> different numbering system would be a nice thing
>>
>> 2. I do like involving the year, but I think 2008/2009/2010 are much 
>> clearer then 2.8/2.9/3.0 let people shorten it verbally, but still realize 
>> that it's a full year being referred to.
>>
>> 3. avoid using the month of the release (which ubuntu does), first you 
>> aren't going to predict the month of relese ahead of time (so what will 
>> the -rc's be called, the year is fairly clear and it's not _that_ bad if 
>> 2008.4 happens to come out in Jan 2009). also too many people don't 
>> understand that 8.10 is between 8.9 and 8.11, not between 8.0 and 8.2
> 
> That's probably why openbsd jumps from 3.9 to 4.0. I like such a numbering
> too. It compacts 3 numbers into 2 (like we had before) but without any
> major/minor notion. You just bump each new version by 0.1 at a somewhat
> regular rate. Having the year and a sub-version is fine too, but I think
> it adds unnecessary digits. Or maybe jump to 8.X for 2008, then 9.X in
> 2009 and 10.X in 2010 ? That way, we have both the date and the simplicity.
> And it's not like we really care about version 1000 in year 3000.

I like the OpenBSD versioning as well. But they only have two releases a
year, so their number should grow slower. Using the same versioning to
linux will end up getting us to very large numbers that have no meaning.
It's basically the same as what's going on now.

I think using the year is the best idea. For instance, debian etch comes
with linux 2.6.18, it would be nice if the users could easily know how
old that actually is.

I think 8.X for 2008, 9.X for 2009 should be great. It's good enough so
none (or almost none) of us will live to see a need for changing it.
Assuming people from 2101 would rather see 1.X than 101.X. Anyhow, will
linux even survive that long with the same name, development model, etc?
Not very likely.

>> so my prefrence (mild as it is) goes to YYYY.r.s (r=release, s=stable)
> 
> agreed, but with Y.r.s :-)
> 
> Willy
>