Farewell To The Linux 2.6 Kernel?

[phoronix]

Phoronix: Farewell To The Linux 2.6 Kernel?

Version 2.6 of the Linux kernel was released in late 2003 and since then the developers have stuck with the 2.6.x.y version numbering. It's been five years with the stable Linux 2.6 kernel, but a proposal has been made on the Linux kernel mailing list to change this scheme...

http://www.phoronix.com/vr.php?view=Njc5MQ

[deanjo]

Personally I think this would be a stupid idea. To track a kernel release history would be a pain in the ass between the RC's and final. Hell even MS abandoned such stupid release monikers after Win 2k.

ie
2009.1.1 RC1
2009.2.23 RC2
.....
2009.4.13 final

[d2kx]

The last number is the patch version I guess. Development of the next kernel for example:

2009.1 RC1
2009.1 RC2
2009.1 RC3
2009.1.0 Final
2009.1.1 (some fixes)
2009.1.2 (some fixes)
...

[deanjo]

The last number is the patch version I guess. Development of the next kernel for example:

2009.1 RC1
2009.1 RC2
2009.1 RC3
2009.1.0 Final
2009.1.1 (some fixes)
2009.1.2 (some fixes)
...

That would be great if they could go from RC to final in a period of a month.

[Michael]

That would be great if they could go from RC to final in a period of a month.

The aa in YYYY.aa.bb wouldn't be the month but just the release number so far that year, so the month doesn't matter at all.

[d2kx]

They could also do a

2008.10 RC1
2008.10 RC2
2008.11 RC3
2008.11 RC4
2008.12.0 Final

So that the current month is the version. I personally would like it that way, but the other ways (minus Linux 3) are good, too. Linux 2.6.x doesn't mean anything anymore.

[deanjo]

The aa in YYYY.aa.bb wouldn't be the month but just the release number so far that year, so the month doesn't matter at all.

OK but I really don't see the value of having a year used as a version number especially in a project that does not comply to any real set release dates or schedule.

[JeanPaul145]

OK but I really don't see the value of having a year used as a version number especially in a project that does not comply to any real set release dates or schedule.

I'm in 100% agreement with you.
In addition to that, there's nothing intrinsically wrong with the current version naming scheme. I like the fact that it has used the same scheme for the last 4-5 years, it makes it dependable. Changing it would only lead to confusion, much like how Nvidia has messed up their versioning schemes with some cards the GeForce 9xxx series basically being re-branded 8xxx series cards, and others having a completely redesigned GPU.

I vote for keeping the 2.6.x versioning until the end of time!:D
(or until changes of significant magnitude are made to justify a 2.8.x or even 3.0 release):p

[3vi1]

If my opinion meant anything (which it doesn't) I would vote to go with the time base numbering - but drop the stupid Millennium and century. It would have the added benefit of putting the major numbers in sync with Ubuntu, and put the current number 1 ahead of the next Windows release. :p

Kubuntu 8.10, with kernel 8.27.7!

And, only when a minor number changes should the major number change. Also, patch levels should never change the major number. That is to say - at the stroke of midnight 8.28-12 does not become 9.28.12. The next patch would still be 8.28.13... etc. 9.29.1 would be the first "new" kernel. Let the minor revision climb until there's an major re-architecture of some piece of the kernel.

-J

[deanjo]

It would have the added benefit of putting the major numbers in sync with Ubuntu,

Linux does not revolve around ubuntu. Ubuntu's numbering scheme makes sense for them as they release on set schedules like clockwork. This does not apply to the kernel at all (or any other real opensource project). It's a lot easier to package a bunch of software together then it is to develop where unforseen events can delay a working release ranging from days to months to years.

[3vi1]

Linux does not revolve around ubuntu.

LoL... I never said it did. That was kind of a joke. Calm down and browse to the website of your favorite distro.

I still like the idea of numbering by time, because it makes you aware of the progress. If 2.6 is going to be on the front of everything from now on... why even have it?

I have another idea: how about we drop the major and minor revision levels, and use latitude and longitude? I mean, if we're going to use the fourth dimension for one of the numbers... why not have the other two relate to where Linus was sitting when he did the commit?

-J

[deanjo]

I still like the idea of numbering by time, because it makes you aware of the progress. If 2.6 is going to be on the front of everything from now on... why even have it?


I would see nothing wrong with going to a new major number. Enough has changed IMHO from 2.6.0 that it warrants it. I just don't think the numbering system should be tied to a value of no real relevance to it's development. Dates are what time stamps are for.

[3vi1]

I would see nothing wrong with going to a new major number. Enough has changed IMHO from 2.6.0 that it warrants it. I just don't think the numbering system should be tied to a value of no real relevance to it's development. Dates are what time stamps are for.

I can respect that opinion. I wouldn't be adverse to losing the first two digits entirely... it just seems that the version numbers might continue rising at a pace that makes non-techies "feel" it's unstable.

[hdas]

there are better things to bother about than this ;). and i am sure this is almost like the last thing that would come to anyone's mind :D.

[JeanPaul145]

If my opinion meant anything (which it doesn't) I would vote to go with the time base numbering - but drop the stupid Millennium and century. It would have the added benefit of putting the major numbers in sync with Ubuntu, and put the current number 1 ahead of the next Windows release. :p

Kubuntu 8.10, with kernel 8.27.7!

And, only when a minor number changes should the major number change. Also, patch levels should never change the major number. That is to say - at the stroke of midnight 8.28-12 does not become 9.28.12. The next patch would still be 8.28.13... etc. 9.29.1 would be the first "new" kernel. Let the minor revision climb until there's an major re-architecture of some piece of the kernel.

-J

This would only lead to more confusion, the current scheme is easier to understand and works fine. Also, like deanjo said, time-based numbering makes no sense for most OSS projects since they will release when they feel the release is ready, not because of some deadline approaching (some exceptions being Ubuntu, Fedora, Gnome, KDE, etc etc).

[[Knuckles]]

Honestly, the kernel version doesn't matter to most users. To the rest of us, we have one we already understand quite well, and are used to, so why change it "just because"?

I for one like the current scheme. It's simple and it works. So I hope they'll stick around to 2.6.30 (hey, 2.0 got up to 2.0.40, so what's the problem?) and beyond.

[Sinner]

I have another idea: how about we drop the major and minor revision levels, and use latitude and longitude? I mean, if we're going to use the fourth dimension for one of the numbers... why not have the other two relate to where Linus was sitting when he did the commit?

-J

That would be cool! Weird, but cool! But it should be in UTM not lat+long, UTM would make it just at tad more confusing :-P

/Sinner

[aaaantoine]

We could just assume the 2.6 and call it 28, 29, 30 from now on, per one of the suggestions listed in the article. I kinda like that idea.

Before 2.6.27 came out, I tried explaining to someone that the next version of the Linux kernel would have the Atheros drivers in it. Saying "Two point six point twenty-seven" out loud was clunky and overwhelming.

[3vi1]

... UTM would make it just at tad more confusing :-P

/Sinner

Okay, I'm for it then. :p

[3vi1]

We could just assume the 2.6 and call it 28, 29, 30 from now on, per one of the suggestions listed in the article. I kinda like that idea.

As I said to another: I'm not against that idea - it would eliminate the numbers that are no longer relevant, and that's a good thing. The only fear I have is that neophytes might say "VERSION 28?!?! SOUNDS LIKE THEY HAVE TO KEEP UPDATING IT TO FIX BUGS!!!"

I know: It's a ridiculous age we live in, where you need to keep version numbers between 5 and 10 for consumer confidence and emotional reasons. If Linus did decide to drop the first two numbers, I would fully support it and correct any online misconceptions I saw stated based on the high rate of change in the version numbers.

Hey... why does the spell-checker think "online" is misspelled?

[deanjo]

I think they should just start using binary for version numbers.
ie:

Kernel 10.110.11100

[3vi1]

I think they should just start using binrary for version numbers.
ie:

Kernel 10.110.11100

Okay... I change my vote to THAT.

[seba]

i don't like it at all. Just keep it simple like today. Whats wrong with having a 2.7.x, 2.8.x, 2.9.x, 3.0, etc. It is simple and we can clearly see which version is newer.

[SavageX]

Hmmm... I for sure would like something different than 2.6.xxx. Given how long "2.6" is around this prefix doesn't give much information anymore. How "old" e.g. is 2.6.13? Well, it's like "14 versions old", which give a rough idea of "outdated", but if this is how versions are compared one could just as well drop the "2.6" and call it "Linux 27", "Linux 28", ... which looks pretty stupid.

So I'd definately appreciate the year (and if possible/meaningful month, too) to be in the version number, so one can relate to it on a human scale.

[khaije1]

This would be a big step in the wrong direction and really should be resisted. The current linux versioning scheme reflects the actual work, the actual technical milestones, and the relative stability of the kernel. Do I care what year and month it was released? No, because with this model of development progress is measured in work and innovation accomplished not predetermined product shipping deadlines.

Those people who wish to replace 2.6.27 with "linux 2008 SP3" need to have their heads examined.

[deanjo]

Hmmm... I for sure would like something different than 2.6.xxx. Given how long "2.6" is around this prefix doesn't give much information anymore. How "old" e.g. is 2.6.13? Well, it's like "14 versions old", which give a rough idea of "outdated", but if this is how versions are compared one could just as well drop the "2.6" and call it "Linux 27", "Linux 28", ... which looks pretty stupid.

So I'd definately appreciate the year (and if possible/meaningful month, too) to be in the version number, so one can relate to it on a human scale.


Sorry, don't mean to sound like a troll with this reply but why doesn't Nexiuz follow this scheme then?

This would be a big step in the wrong direction and really should be resisted. The current linux versioning scheme reflects the actual work, the actual technical milestones, and the relative stability of the kernel. Do I care what year and month it was released? No, because with this model of development progress is measured in work and innovation accomplished not predetermined product shipping deadlines.

Those people who wish to replace 2.6.27 with "linux 2008 SP3" need to have their heads examined.

Amen