First things first, I would like to know what prompted the change from 2.4 to 2.6 kernels. I know that the change had to do with the development version, the 2.5 tree and the massive amounts of patches distros had to carry. Aside from this i think it was also the scheduler changes that prompted the 2.6 version, but I don't know all that much about it and any other comments about the change would be great.
Second I wanted to talk about the linux 2.7.x kernel, whats in the making or maybe even not started, that could prompt a change to a 2.7 version kernel, i know that a lot of good changes are going into the kernel as part of the rcX kernels in the 2.6 version. Would we continue to see 2.6 kernels until some big problem shows its head and we all go "oh sh**" and then change something so massive that it prompts the change or are we going to continue with the 2.6 tree. I just want to get some information and peoples opinions on this, just to see where things are headed.
> Second I wanted to talk about the linux 2.7.x kernel, whats in the > making or maybe even not started
Nothing.
I'm not going back to the old model. The new model is so much better that it's not even worth entertaining as a theory to go back.
That said, I _am_ considering changing just the numbering. Not to go back to the old model, but because a constantly increasing minor number leads to big numbers. I'm not all that thrilled with "26" as a number: it's hard to remember.
So I would not dismiss (and have been thinking about starting) talk about a simple numbering reset (perhaps yearly), but the old model of 3-year developement trees is simply not coming back as far as I'm concerned.
In fact, I think the time-based releases (ie the "2 weeks of merge window until -rc1, followed by roughly two months of stabilization") has been so successful that I'd prefer to skip the version numbering model too. 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.
So if the version were to be date-based, instead of releasing 2.6.26, maybe we could have 2008.7 instead. Or just increment the major version every decade, the middle version every year, and the minor version every time we make a release. Whatever.
But three-year development trees with a concurrent stable tree? Nope. Not going to happen.
>> Second I wanted to talk about the linux 2.7.x kernel, whats in the >> making or maybe even not started
> Nothing.
> I'm not going back to the old model. The new model is so much better that > it's not even worth entertaining as a theory to go back.
I would also recomend staying away from the old model
> That said, I _am_ considering changing just the numbering. Not to go back > to the old model, but because a constantly increasing minor number leads > to big numbers. I'm not all that thrilled with "26" as a number: it's hard > to remember.
The main reason I asked these questions is because we have 2.4.36 and 2.2.27 and those are pretty high numbers, so I thought maybe we would start 2.7.x releases just so that they start back at 1
> So I would not dismiss (and have been thinking about starting) talk about > a simple numbering reset (perhaps yearly), but the old model of 3-year > developement trees is simply not coming back as far as I'm concerned.
> In fact, I think the time-based releases (ie the "2 weeks of merge window > until -rc1, followed by roughly two months of stabilization") has been so > successful that I'd prefer to skip the version numbering model too. 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.
Does it have to be even numbers only?
> So if the version were to be date-based, instead of releasing 2.6.26, > maybe we could have 2008.7 instead. Or just increment the major version > every decade, the middle version every year, and the minor version every > time we make a release. Whatever.
I dont think people would agree with the 2008.7 version numbers although it would make them more aware of how old the kernel and prompt them to upgrade
> But three-year development trees with a concurrent stable tree? Nope. Not > going to happen.
> > 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.
> 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..
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.
And yes, something like "2008" is obviously numerically bigger, but has a direct meaning and as such is possibly better than something arbitrary and non-descriptive like "26".
Let the bike-shed-painting begin.
(I had planned on taking this up at the kernel summit, where the shed painting is at least limited to a much smaller audience, but since you asked..)
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
so my prefrence (mild as it is) goes to YYYY.r.s (r=release, s=stable)
> 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.
> And yes, something like "2008" is obviously numerically bigger, but has a > direct meaning and as such is possibly better than something arbitrary and > non-descriptive like "26".
> Let the bike-shed-painting begin.
> (I had planned on taking this up at the kernel summit, where the shed > painting is at least limited to a much smaller audience, but since you > asked..)
On Mon, Jul 14, 2008 at 08:55:59PM -0700, da...@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.
> so my prefrence (mild as it is) goes to YYYY.r.s (r=release, s=stable)
Willy Tarreau wrote: > On Mon, Jul 14, 2008 at 08:55:59PM -0700, da...@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)
On Tue, Jul 15, 2008 at 12:31 AM, Willy Tarreau <w...@1wt.eu> wrote: > On Mon, Jul 14, 2008 at 08:55:59PM -0700, da...@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.
>> so my prefrence (mild as it is) goes to YYYY.r.s (r=release, s=stable)
> agreed, but with Y.r.s :-)
Interesting idea but that would still get us to the 20.1.5 and that just seems really high, even if its based on year not on number of releases. Although I still wanted to know about the original change between 2.4 to 2.6 and what other then the version numbering prompted the change
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Mon, 2008-07-14 at 19:47 -0700, Linus Torvalds wrote: > On Mon, 14 Jul 2008, Stoyan Gaydarov wrote: > > > 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.
> > 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.
ACK. "Normal" users (and especially average journalists where most "normal" users get their knowledge from) tend to know of "odd Linux kernel version are development" (and will probably report it wrongly that way if "2.7 is released"). Perhaps they learn the new model if 2.7 will never have existed and people asked about.
[...]
> 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
ACK, probably the best. But others are surely better in proposing beautiful colors.
[....]
Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services
> So if the version were to be date-based, instead of releasing 2.6.26, > maybe we could have 2008.7 instead. Or just increment the major version > every decade, the middle version every year, and the minor version every > time we make a release. Whatever.
Or you could just do it like emacs or Solaris and simply use a single number.
>> So if the version were to be date-based, instead of releasing 2.6.26, >> maybe we could have 2008.7 instead. Or just increment the major version >> every decade, the middle version every year, and the minor version every >> time we make a release. Whatever.
>Or you could just do it like emacs or Solaris and simply use a single number.
And both emacs and Solaris already have high numbers. For the former that's probably warranted given its long existence. Solaris, hm no, but the "SunOS 5.11" tag on the other hand, is quite "acceptable".
Big numbers tend to be forgotten. Do you know offhand what the latest MSOffice is? emacs? udev? less? I doubt you do. My intuitive answers were: 12, 22, "somewhere in the 100s", "somewhere in the 400s". Reality? I had to look up the last two. 12(.with.an.oodle.of.digits), 22.2, 124, 418/424(beta). Maybe Linux would be different because you see the version on some login prompts, dmesg, or similar. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Mon, 2008-07-14 at 19:47 -0700, Linus Torvalds wrote:
> On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
<snip> > Let the bike-shed-painting begin.
> (I had planned on taking this up at the kernel summit, where the shed > painting is at least limited to a much smaller audience, but since you > asked..)
I like the current numbering fine.. my suggestion is to keep the current model, there are various reasons
1: it requires no effort 2: various things doesent break 3: naming isnt _THAT_ important
then you could increment the major number once something very important happens, such as going to 2.8 when the removal of the BKL or something.
On Mon, 14 Jul 2008, Linus Torvalds wrote: > I think the time-based releases (ie the "2 weeks of merge window until -rc1, > followed by roughly two months of stabilization") has been so successful that > I'd prefer to skip the version numbering model too. 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.
> So if the version were to be date-based, instead of releasing 2.6.26, > maybe we could have 2008.7 instead. Or just increment the major version > every decade, the middle version every year, and the minor version every > time we make a release. Whatever.
Well, we just haven't had anything big enough to merit an increase in the minor number lately. I nominate the removal of the BKL as one such feature, based on the sheer work required and how many modules you'll need to touch to do so. In fact, it would be the natural conclusion to a 2.x series that highlighted SMP as its primary new feature.
But it's hard now to predict future milestones, or when an overall paradigm shift might happen. In those cases you'll want to give Linux a bright new announcement to the world, instead of it being "just another standard year of kernel development".
Remember, you used to have versions called 1.3.100 before -- and they seemed perfectly normal back then. I personally like how we're still on 2.y.z numbers compared to all of the other OSes (Solaris 11, HP-UX 11)...it makes Linux still feel young, showing how much better it can get ;-)
So I vote for releasing by "features" still, and keep the current numbering scheme. Who knows when the next big idea will pop up that's worthy of 3.0.0.
[Linus Torvalds - Mon, Jul 14, 2008 at 07:22:04PM -0700] | | | On Mon, 14 Jul 2008, Stoyan Gaydarov wrote: | > | > Second I wanted to talk about the linux 2.7.x kernel, whats in the | > making or maybe even not started | | Nothing. | | I'm not going back to the old model. The new model is so much better that | it's not even worth entertaining as a theory to go back. | | That said, I _am_ considering changing just the numbering. Not to go back | to the old model, but because a constantly increasing minor number leads | to big numbers. I'm not all that thrilled with "26" as a number: it's hard | to remember. | | So I would not dismiss (and have been thinking about starting) talk about | a simple numbering reset (perhaps yearly), but the old model of 3-year | developement trees is simply not coming back as far as I'm concerned. | | In fact, I think the time-based releases (ie the "2 weeks of merge window | until -rc1, followed by roughly two months of stabilization") has been so | successful that I'd prefer to skip the version numbering model too. 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. | | So if the version were to be date-based, instead of releasing 2.6.26, | maybe we could have 2008.7 instead. Or just increment the major version | every decade, the middle version every year, and the minor version every | time we make a release. Whatever. | | But three-year development trees with a concurrent stable tree? Nope. Not | going to happen. | | Linus |
Hi to all! Since I've been Cc'ed :) I think I'm not the right person to be asked about numbering scheme (and since I'm not that long in kernel) BUT actually I think there is only one question - it's not about how to number the kernel but rather what we trying to say by numbering scheme. Some areas should be distinguished:
- development/stable team - distros - regular users
Most developers work with git trees and rather carries about sha1 then a version number :) So eventually numbering scheme is not that important for developers by its own.
Distros - well, i think distros use they own scheme anyway so they don't really care about kernel versioning scheme (Gentoo-2008, Fedora-9, Ubuntu-8.04...)
So we have the quite large group of people which should be considered for convenient versioning scheme - _regular users_. Lets say I'm a regular user - the most convenient scheme for me would be YYYY.r.s i think since it tells me - this kernel is fresh enough to be used on my shining laptop, and maybe it even supports all hardware I have! And at least it looks good -
> Or you could just do it like emacs or Solaris and simply use a single number.
No - because then those handful of Solaris supporters will get one more 'proof' in support of their claims of Linux copying Solaris - first SystemTap copying DTrace and now version numbers. See how we stand a risk of ending up convinced we do not innovate?
On the other hand with Emacs style numbering - I am afraid Linus will be severely tempted not to make a release in years or worse yet we would have a rename on our hands - GNU/Emacs/Linux
Areas? "Target audience groups" maybe? Well, I'm also not a native English writer ;-)
> - development/stable team > - distros > - regular users > So we have the quite large group of people which should be considered for > convenient versioning scheme - _regular users_. Lets say I'm a regular user - > the most convenient scheme for me would be YYYY.r.s i think since it tells > me - this kernel is fresh enough to be used on my shining laptop, and maybe > it even supports all hardware I have! And at least it looks good - > Linux-2008.0.0
So, the version numbers aren't important for anyone else than "regular users"? Ok, I'm a "regular user", so then I'm qualified to comment ;-)
Microsoft has attempted using year numbers in their releases, do we really want to go the same way? ;-) Well, indeed - my vote goes in the direction of YYYY.r.s. I have one concern though, such a release could easily be mistaken for beeing an actual date. Maybe better to write 2008.r1.s1 to make it explicit it isn't the release date? 2008.r1.s1 would at a glance easily give me an impression on whether the kernel version is "outdated", "mature" or "fresh". 2008.r1.s1 is easily googlable (though googling for "linux changelog 2.6.25" isn't really that difficult)
That being said, is it really reasonable to assume the linux kernel will continue evolving gradually for all future? In all software, sometimes it is really needed to make some major changes, break backward compatibility and decrease the stability - and that's what the major version numbers are for. I think saying "we'll never need to change the major version number again" is roughly equivalent with "the design of Linux 2.6 is perfect". Or, maybe some years or decades down the road we'll all upgrade to something with a different name than Linux ;-)
> So if the version were to be date-based, instead of releasing 2.6.26, > maybe we could have 2008.7 instead. Or just increment the major version > every decade, the middle version every year, and the minor version every > time we make a release. Whatever.
The Altera Quartus tool series have version 8.x for all the versions released in 2008; they've followed that scheme since 2002. I think it took until 2005 until anyone outside Altera noticed, but it was reasonably clean. Presumably it will be 10.x in 2010.
Clearly, the 2. prefix has long outlived its usefulness as far as Linux is concerned, and probably the 6 as well. I personally don't think two-digit numbers are a big problem, although three-digit numbers *are*, which is probably why a lot of software has x.xx format version identifiers.
> On Mon, 14 Jul 2008, Stoyan Gaydarov wrote: >>> 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. >> 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..
It occurred to me that another approach might make sense:
Linux was released in 1991 with a 1.0 in 1994, correct? So, why not make 1991 sort of the Linux Epoch? The major number would be the decade since Linux' release (this being the second decade of Linux, it works well) and the minor number could be the year within that decade of releases.
I like this idea personally because it doesn't break the current numbering scheme (2.7 is still skipped, though) and it can be self-consistent for a number of years. When Linux reaches its fifth decade and its midlife crisis, it'll be in version 5.0.
> 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.
> And yes, something like "2008" is obviously numerically bigger, but has a > direct meaning and as such is possibly better than something arbitrary and > non-descriptive like "26".
> Let the bike-shed-painting begin.
> (I had planned on taking this up at the kernel summit, where the shed > painting is at least limited to a much smaller audience, but since you > asked..)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIfOcLi1yS1BuzIvgRAnW9AKCSBqFsctCS58XdZ81QdnSuMB4WpQCfbPTf qTRm2dSF6OyvyTrN8cR4XzM= =VcmW -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Mon, Jul 14, 2008 at 07:47:46PM -0700, Linus Torvalds wrote:
> On Mon, 14 Jul 2008, Stoyan Gaydarov wrote:
> > > 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.
> > 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..
> 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 2.6. prefix is like with X which is version 11 for 20 years and still counting.
Or like with X11R6, that became X11R7 after 11 years, there might be in a few years some big change that will warrant a 2.8 or 3.0 (the rewrite of the kernel in Visual Basic .NET ;-) ).
But my personal opinion is that we now have an established version numbering with the current development model that is 2.6.x, and users got used to it.
If you'd change it you will only create confusion - e.g. with your 2.9.1 idea half the world will see that 9 is an odd number, remember the old kernel versioning, and think this is the first development release towards 3.0...
> Linus
cu Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
> Clearly, the 2. prefix has long outlived its usefulness as far as Linux > is concerned, and probably the 6 as well.
Been calling the -stable branches v20, v21, v22, ... here.
I do believe the numbering scheme should at least ostensibly still be feature driven, not be a fully robotic date thing. With the latter, you definitely miss out on press-opportunities and that's not even meant cynical. There just is a bit of industry around Linux and the promotion opportunities of (say) "Linux 3" are really lots, lots bigger than anything boringly date based.
That even holds for things like books -- I just bet that a "all new, covers Linux 3!" blurp on the cover sells lots more copies than a "all new, covers the march 21st 2009 version of Linux!" one.
But yes, the current monotic increase is definitely getting a bit boring as well. The kernel as of 2.6.26 is quite different from the kernel that was known as 2.6.0 so just be creative I'd say and set a 2.8 goal. Next version can be 2.9 (should be clear enough by then) and then watch world domination happen with the big 3.0 release.
Rene Herman wrote: > On 15-07-08 20:04, H. Peter Anvin wrote:
>> Clearly, the 2. prefix has long outlived its usefulness as far as >> Linux is concerned, and probably the 6 as well.
> Been calling the -stable branches v20, v21, v22, ... here.
> I do believe the numbering scheme should at least ostensibly still be > feature driven, not be a fully robotic date thing. With the latter, you > definitely miss out on press-opportunities and that's not even meant > cynical. There just is a bit of industry around Linux and the promotion > opportunities of (say) "Linux 3" are really lots, lots bigger than > anything boringly date based.
And that's why after the adoption of generics and a few things java all the sudden became java 5. I don't like that. I hope the world gets used to learning things instead of just being driven by a pretty number. And I think that not using marketing numbers on a popular software is a good step into helping people realise that version numbers are meant to keep track of the changes not to look cool.
> That even holds for things like books -- I just bet that a "all new, > covers Linux 3!" blurp on the cover sells lots more copies than a "all > new, covers the march 21st 2009 version of Linux!" one.
I rather just have good books around. I can bet that all -- or at least most of -- those new "LINUX 3!" books would suck. So it's better if they sell little or not sell at all.
> But yes, the current monotic increase is definitely getting a bit boring > as well. The kernel as of 2.6.26 is quite different from the kernel that > was known as 2.6.0 so just be creative I'd say and set a 2.8 goal. Next > version can be 2.9 (should be clear enough by then) and then watch world > domination happen with the big 3.0 release.
Well, if 2.6.0 was 3.0 (2003.0) then people would easily realise that they're missing 5 years of kernel development. Given that hint, if they take a look on a few Changelogs they'll soon find out they're missing on quite a lot.
> Linux 2010.5? Boooooooooring....
Well, it is software versioning and not Gisele Bündchen taking off her top.
> Rene Herman wrote: >> I do believe the numbering scheme should at least ostensibly still be >> feature driven, not be a fully robotic date thing. With the latter, you >> definitely miss out on press-opportunities and that's not even meant >> cynical. There just is a bit of industry around Linux and the promotion >> opportunities of (say) "Linux 3" are really lots, lots bigger than >> anything boringly date based.
> And that's why after the adoption of generics and a few things java all > the sudden became java 5. I don't like that. I hope the world gets used > to learning things instead of just being driven by a pretty number.
I don't. I hate bores.
More importantly though, that's really the kind of thing where you can argue about how life should and/or could be until you're blue in the face but if it isn't, it doesn't actually matter any. People intimately involved with a project like Linux (say, subscribers to this list) definitely look quite different at it than others and that's nothing bad. Communicating information to these people through shortcuts like version numbers isn't necesarily anything to avoid.
There ARE features in the pipeline you could plan for that would warrant a version jump. I'd for example consider being able to run X not as root a very worthy goal for a version jump (be it 2.8 or 3.0). That's also a change in the area where those that are NOT intimately involved yet interested in a more than professional way are -- on the desktop.
Really. I'd like it much better if the big cool feature of the all new Linux kernel would be running X as user, rather than when the big cool feature of X running as a user would require a version of Linux newer than the february 2010 release.
If you get what I mean. Do trust me, you'll have time and opportunity enough in your lifetime to be boringly professional.
(and please don't drop CCs on linux-kernel. I for example in this case would like the X as user thing to be noticed as I believe it's a nice point as an "externally significant" thing)
> Rene Herman wrote: >> I do believe the numbering scheme should at least ostensibly still be >> feature driven, not be a fully robotic date thing. With the latter, you >> definitely miss out on press-opportunities and that's not even meant >> cynical. There just is a bit of industry around Linux and the promotion >> opportunities of (say) "Linux 3" are really lots, lots bigger than >> anything boringly date based.
> And that's why after the adoption of generics and a few things java all > the sudden became java 5. I don't like that. I hope the world gets used > to learning things instead of just being driven by a pretty number.
I don't. I hate bores.
More importantly though, that's really the kind of thing where you can argue about how life should and/or could be until you're blue in the face but if it isn't, it doesn't actually matter any. People intimately involved with a project like Linux (say, subscribers to this list) definitely look quite different at it than others and that's nothing bad. Communicating information to these people through shortcuts like version numbers isn't necesarily anything to avoid.
There ARE features in the pipeline you could plan for that would warrant a version jump. I'd for example consider being able to run X not as root a very worthy goal for a version jump (be it 2.8 or 3.0). That's also a change in the area where those that are NOT intimately involved yet interested in a more than professional way are -- on the desktop.
Really. I'd like it much better if the big cool feature of the all new Linux kernel would be running X as user, rather than when the big cool feature of X running as a user would require a version of Linux newer than the february 2010 release.
If you get what I mean. Do trust me, you'll have time and opportunity enough in your lifetime to be boringly professional.
>The 2.6. prefix is like with X which is version 11 for 20 years and >still counting.
>Or like with X11R6, that became X11R7 after 11 years, there might be >in a few years some big change that will warrant a 2.8 or 3.0 (the >rewrite of the kernel in Visual Basic .NET ;-) ).
Jumping the major number would really require some big flag day. What was it that made the jump from 1.x to 2.0? (Some ABI change w.r.t. binaries -- ELF becoming standard maybe?) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
