login
Search
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. -Stoyan G --
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 --
On Mon, Jul 14, 2008 at 9:22 PM, Linus Torvalds 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 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 --
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..) Linus --
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) --
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. agreed, but with Y.r.s :-) Willy --
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? --
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 -Stoyan --
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. 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 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. --
Continuing on that thought.. Incrementing the minor number once every 6 to 8 releases or so (resetting the micro number to 0 of course) would nicely mark a group of featureful kernels. --
Use 2.8 in 2008, 2.9 in 2009, 2.10 in 2010, etc? Craig Milo Rogers --
Actually, I did, which was why I thought my succinct sequence was sufficient. Here's what I meant to convey, in words: use the millennium as the major version number, the year-of-millennium as the minor version number, and (by implication) the usual release and stable suffixes. This sequence had not been proposed yet in the thread, perhaps for some reason like it's a stupid idea, since it will soon violate the largish meaningless number rule in the year-of-millennium. In case you think I'm mistaken in my assertation that it hasn't been proposed before in the thread, the rest of this message summarizes the pertinent posts in the thread: In <alpine.LFD.1.10.0807141914280.3017@woody.linux-foundation.org>, Linus Torvalds proposed two possible new patterns: yyyy.month decade.year.release In <alpine.LFD.1.10.0807141939410.3017@woody.linux-foundation.org>, Linus Torvalds proposed this pattern: 2.8.release in 2008, 2.9.release in 2009, 3.0.release in 2010 Linux also expressed a dislike for large, meaningless numbers. In <alpine.DEB.1.10.0807142048260.6370@asgard>, David Lang expressed a preference for yyyy.release, and expressed a dislike for yyyy.month on two grounds: 1) it's hard to predict the release month, so how should the -rc's be named, and 2) some people don't understand that 8.10 comes after 8.9. He then proposed: yyyy.r.s (r=release, s=stable, as at present) In <20080715053101.GJ1369@1wt.eu>, Willy Tarreau proposed: y.r.s (y = yyyy - 2000), e.g. use 9.r.s in 2009, 10.r.s in 2010 In <487C4646.7020905@gmail.com>, Rafael C. de Almeida seconded 8.x, 9.x, 10.x, and commented that neither Linux nor any of us would live long enough to worry about 101.x. [I eschew such pessimism. :-)] There were some comments that didn't propose alternative sequences (which I may skip mentioning from here on), then in <87skubxxtq.fsf@basil.nowhere.org> Andi Kleen proposed using a single number like Solaris. In <20080715133801.546338c1@the-village.bc.nu>, Alan Cox ...
Nonono, that's all backwards! This is about having a 3.0 release BRING ABOUT world domination! </tongue in cheek> and all but that was my point -- with a not at least ostensibly feature driven scheme you loose out on all the hype, press, marketing and, frankly, on the fun. Really, find me a single Linux developer who wouldn't try just a little bit harder for a big 3.0 release. This is still a community, not yet a boring office schedule... Rene. --
I'm afraid that the allure of 3.0 would mean that everyone would want to get their shiny new subsystem/scheduler rewrite/bootstrap file format change/whatever incorporated into it, resulting in a protracted integration period and an unstable system. According to this line of thought, Linus should simply announce version 3.0 with no forewarning... Craig Milo Rogers --
not to mention that people would avoid it becouse it would be a .0 release and therefor perceived as being unstable (and for the reasons that Craig lists, they would probably be right) David Lang --
Which is why it should not be announced early, but happen Maybe we should also start skipping on numbers like 2.x.4, 2.x.13, and 2.6.66. "What's in a number?" Maybe we should only ever release 2.<odd>.0 to show that there is nothing bad about being an <odd> or a .0 release. --
Or better yet, we'd have 342 -rc's and a REALLY big party when 3.0 finally hits the streets. See. You guys just don't think "fun"... Rene. --
I suggest that major and minor versions follow some milestones (as suggested to a message that I cannot reply directly). For example: Starting from 'today', mark all open bugs and change version to 2.7 when all those bugs are closed. Then mark the open bugs of that time and change to 2.8 when those bugs are fixed. Repeat as needed. Set a 'target'/goal and change version to 3.0 whenever worldwide linux server/desktop percentage reaches XX%. (Of course this may happen before changing to 2.7 but this is not a bad thing (tm)). Then set another target (that may not be related to linux adoption) etc, etc... This will keep the current versioning scheme, set some common goals for all developers, add more meaning into trying to fix bugs and prevent the world from experiencing large linux version numbers. As a side-effect, setting targets like those may make the whole community cooperate even more/better by having common long-term goals. ... p.s You could also keep the X.Y.Z notation and change the major version number whenever the way of versioning changes (and the current one is actually version 2) :P --
Actually he said rename 2.6.28 to 2.8.0 or rename 2.6.29 to 2.9.0 or rename 2.6.30 to 3.0.0 i.e. .. whatever you are doing now, just drop the first two numbers (the "2.6" bit) since they seem to be constant. I don't know where the idea you propose above came from, and I don't quite understand it either! Remember that Linus' only objective is to have smaller numbers, which may therefore 1) be memorable 2) be good advertising copy 3) be meaningful and that was the only intention of my scheme: "drop the constant bit". Peter --
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? 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 --
The point is to rebase to a new system at a point coming up which is convenient. There is an opportunity at 2.6.28, which can be renamed 2.8.0, dropping the constant 2.6. I suppose one counts 2.8.1, 2.8.2 from then on, or does whatever else one wants to do. I don't know - Linus' only objective is to get smaller more meaningful numbers and the details of how one counts afterwards don't matter. Or if one misses the 2.6.28 point, one gets another good opportunity for rebasing at 2.6.30, which could become 3.0.0, dropping the constant 2.6 We need smaller numbers now. I.e. We're happy with the system we've got, except for the high numbers we're at, so just rebase. Peter --
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. 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 --
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. mvh. Kasper Sandberg --
Sorry for entering a discussion from a project I'm just a user of, but I was thinking... I do see smallish problems with current scheme: - First two numbers never change (2.6), so they're mostly useless. - Third number gets too big (currently 26, and growing) - Stable releases are already a fourth number (2.6.25.11. Unconfortable). So a possible solution that would not break completely with historical numbers could be: - Since you're aproaching 2.6.30 (around mid 2009), why not agree tu turn that into a 3.0 release? Peope have been expecting a version 3 of the kernel for a long time now... It might give the (false) impression that it's an all new release, but it would be explained that it's just a normal one. However, I also think that by that time, the last "problem" with Linux will be solved, i.e, the graphics thing. With the changes in DRM/DRI starting to appear in 2.6.27 (maybe), they will stabilize through .28 and .29, making .30 a good release to declare the Linux kernel "completely mature", without any weak spot (so to say) and turn it into 3.0 release (the Free drivers for ATI and even NVIDIA will hopefully be mature by then too, as might be Gallium3D, VA-API, GEM/TTM, etc... ) - From there, how to proceed? Instead of making the same mistake again of having a useless middle number, each release would increment by a 10th. That is, instead of 3.0.1, 3.0.2, etc... just 3.1, 3.2, 3.3, etc... Then the stable releases would be 3.1.1, 3.1.2, etc... (no longer a 4 series of numbers). And after 3.9, we would have 4.0 to avoid having again a too bit number (3.26, etc...). Roughly, you release 5 kernels per year, so that would give enough time until you hit a high number (it will increment by one every two years). For example, it would take 20 years from 2009 until you hit version 13.0. Twenty years is a decent amount of time in kernel development. And well, even 13 is not _that_ big anyway. You can push this numbering up to version 20 if necessary and ...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. -----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----- --
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
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
--
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?) --
Another point that came into my mind:
How many scripts and programs out there parse the kernel version number,
know about the 2.6 prefix, and might need an update if it changes?
Not a big deal if a change would indicate a big change like with the old
development model - but IMHO not worth it if there's no compelling
reason why we have to change the numbering at all.
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
--
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. --
No, that would be horrible. The only point of changign the numbering would be to make the numbers smaller. Not fewer. I don't like "26" much as a version number, I'd like "131" even less. So I'd much rather have something like "2.9.1" than "27", just because it's a hierarchy of simpler numbers. Linus --
Oh just like 'less'. I currently have version 418 of less installed it would seem. -- Len Sorensen --
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. -Byron --
Didn't HP-UX 11 come out around a decade ago? Did they stop development? -- Len Sorensen --
The short answer is that HP-UX decided to keep major number 11 as a branding decision, and has released updates such as 11i, 11i v1, 11i v2, etc. Most recent release was 11i v3, and if you do a uname -a, you'll see that you get a "real" version, like 11.31. http://en.wikipedia.org/wiki/Hpux#Versions /ac --
So the 11 no longer has any meaning. At least when Sun decided the 5 in SunOS Version 5.x didn't have a meaning anymore, they dropped it. Of course sun also called it solaris 2.x at the same time as SunOS 5.x, so perhaps dropping everything but the x made sense. Version numbers never stay the way they were intended to. -- Len Sorensen --
Not exactly. The 11 implies an ABI/API guarantee to ISVs and some sense of "stability" (for whatever that means) to end users. Marketing fluff, yes, but I guess some people out there do care about that stuff. /ac --
[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 ...
Areas? "Target audience groups" maybe? Well, I'm also not a native 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 ;-) -- Tobias Brox, 69°42'N, 18°57'E --
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. -hpa --
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. Linux 2010.5? Boooooooooring.... Rene. --
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 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 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 --
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. Rene. --
On 16-07-08 08:55, Rafael C. de Almeida wrote: (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 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. Rene. --
2.6.9 was the last of a sequence of internally compatible kernels.
2.6.16 or 18 or 22 is the last of another such sequence (depending on
what you look at)
2.6.24 probably should have started a new version number.
Peter
--
Why 2008 ? We have lots of year systems beyond the specific Western one. Surely "38." as the Unix epoch time... And .. 2008 sounds so "old Windows numbering" --
