Messages in this thread | | | Date | Tue, 15 Jul 2008 09:49:17 +0200 (CEST) | From | Jan Engelhardt <> | Subject | Re: From 2.4 to 2.6 to 2.7? |
| |
On Tuesday 2008-07-15 04:47, Linus Torvalds wrote: > >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.
Don't discriminate against odd numbers! :) I always wanted to see a 2.<odd> on the mingetty login banner just because that seemed cool, and to hopefully make the last people who would say "but is not that development series?" finally get the clue that Linux is not developed in that way anymore.
[in the previous to the previous mail]: >We don't do releases based on "features" any more, so why should we do >version _numbering_ based on "features"? > >For example, I don't see any individual feature that would merit a jump >from 2.x to 3.x or even from 2.6.x to 2.8.x. So maybe those version >jumps should be done by a time-based model too - matching how we >actually do releases anyway.
Maybe not individual feature, but as a whole. We probably should have jumped when the new model was introduced. Ok, that did not happen, but over time, the kernel's abilities increased and then sometime, there was a release where you would say (as of today) "yes, that kernel back there has been a really good one" where a version jump would have been warranted at the same time. For me, these are 2.6.18, .22, .23 or .25 (pick one). However, there also needs to be a bit of time between minor number bumps, so if 2.6.18 were 2.7.0, 2.6.25 would be the earliest to qualify for a 2.8.0.
My expectation is that 2.6.27 would be the next "good one" where a version jump would go nicely in line. Make it 2.7.0, it got loads of new features compared to 2.6.0 :)
My preference is of course that version numbers run at the same speed as they have been for most of the time now - that is, incrementing the micro as we go. If one were to increment the micro for every release (2.6.18 -> 2.7, 2.6.19 -> 2.8, 2.6.20 -> 2.9) then that is a magnitude higher and thus would count as faster-going.
>Anyway, I have to say that I personally don't have any hugely strong >opinions on the numbering. I suspect others do, though, and I'm >almost certain that this is an absolutely _perfect_ >"bikeshed-painting" subject where thousands of people will be very >passionate and send me their opinions on why _their_ particular shed >color is so much better. > >The only thing I do know is that I agree that "big meaningless numbers" >are bad. "26" is already pretty big. As you point out, the 2.4.x series >has much bigger numbers yet.
2.1.132 is big.
Numbering should be interesting and sometimes unexpected (like when there suddently was a 2.<even>.0 announcement in my mailbox, or the change of development model). The YYYY.r[.s] scheme defeats that, and it counts fast too, though I am not opposed to YYYY.r. What I am against is [YYYY-2008].r (8.0, 8.1, 9.0, etc.) since that may be seen as a version number instead of the year.
| |