Linus on Kernel Version Numbering

walshy007 writes "In a recent thread it was asked what it would take for an 'unstable' 2.7 development tree to be created, to which Linus replied: '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. 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"?'"

Comments

Excellent notion

[MaulerOfEmotards]

Linus' idea to switch to date-based version numbering seems excellent to me. From a psychological perspective, humans have difficulties with numbers, especially larger numbers. Also, a purely incremental numbering system without any external relationships (let's call it "semantic anchors" or something) are just that: numbers. By using dates we tie in with an already establish cognitive category which not only tells us the version but also how old it is. Since we Linux folks are usually very conscious about keeping up-to-date (at least the /. crowd) it would be a good and automatic reminder of the state of our system. That is, we use the "date obsolescence effect" (the reason Microsoft stopped naming their software after the year released) to the advantage for security rather than the disadvantage of negative sales.

Re:Excellent notion

[Tim C]

which not only tells us the version but also how old it is

Who cares how old it is? If it works and isn't known to have any stability or security issues (or at least not ones that affect your use of it), does it matter?

Software that is newer is not inherently more secure, software that is older is not inherently less secure. I really fail to see how this "date obsolescence effect" helps improve security - I know version 20080213 is older than 20080601, but then I also know that 2.2.12 is older than 2.2.25. Neither of these schemes in themselves say anything at all about the security of the software in question.

Re:Excellent notion

[Tom]

date-based is good for continuous processes, which the development isn't and shouldn't be. From the user perspective, my primary concerns are comparisons - is this driver for my kernel version? Do I run the latest kernel version? Is this function available in my current version?

Numbers are easier to compare than dates. They are also international, while dates aren't. 07.01. means 1st of July in some countries and January 7th in others.

Major and minor numbers have their place, too. They tell me something about the amount of change. I'll update from 2.6.25 to 2.6.26 without a second thought, as I expect nothing important to have changed. I'll spend a few minutes on the Changelog when I go from 2.6 to 2.7 because I expect a couple of minor things to have changed. I know that going from 2 to 3 will be a major update and might result in all kinds of incompatabilities, so I'd better make sure all my apps are ready first.

That's why I hate MS year-based versioning system. "Word '97" tells me absolutely nothing about how it compares to '95, '96 or '98. A version number would at least tell me what the manufacturer thinks it's "worth" (even though with MS that was mostly a lie as well).

And if Linus thinks that "big" (26, yeah right) numbers are a problem for people, then dates will be as well. Quick, how many releases were between 2.6.20 and 2.6.24? Good. Now quick, how many days were between January 17 and March 11? And... how many releases?

customers rely on "features"

[Speare]

Er, you don't do a release for specific "features," but once the release has been made, customers rely on knowing what "features" are (or are not) in the release they're using. There should be a sane and rational comparison rule to know if one version is newer (and likely to have more good "features" and fewer bad "features") or not. Ubuntu uses dorky names but anyone who knows the alphabet and the comparison rule can at least decide if "Beaver" is older or newer than "Walrus." I don't care what the kernel uses, but it should be something people can figure out the ordering.

Hey, I heard the Parameterized Ultra-Fair Order One Irreversible Hypoxic Process Scheduler is in the newest kernel. Wait, is that in 2.6.43.-12b34_+omicron-rc6, or not?

Re:Linus...

[setagllib]

http://lxr.linux.no/linux/Documentation/stable_api_nonsense.txt

Summary: Being able to improve the API regularly keeps Linux largely free of legacy cruft that slows down the development and runtime performance of other systems like Windows. That's why Linux maxes out hardware that runs like a dog under Windows.

Re:It also reflects...

[gmack]

There are multiple bugfix only branches. 2.6.16.x to 2.6.25.x are all still actively maintained.

The simple fact is that the new model has actually caused Linux distros to have more stable kernels now that vendors aren't trying to constantly backport things from the unstable branch.

Shorter dev cycles were one of the best ideas Linus ever had.

Re:Why versioning based on features?

[MacColossus]

I agree. Exactly. It aids non linux developers in troubleshooting issues and knowing if package b will work with package a and kernel x or if I need to update to kernel y.

Re:Linus...

[Nevyn]

You can have the best of both worlds (a stable API, and the ability to make changes). The fact of the matter is that the APIs don't change all that often, and frequently they change in a way that would allow for a trivial compatibility layer.

Your argument is basically that writing shared libraries is just as easy as writing applications, and that maintaining API/ABI compatibility in shared libraries is "easy". Both of which contradict years of experience.

And, specifically from the kernel perspective, the usual example is the Solaris kernel in the 2.3/2.4/2.5 timeframe (memory is getting old) where they refused to fix a security bug because it would break ABI compatibility. So the corollary to your argument then is that Solaris kernel engineers are idiots?

Lots of changes from 2.6.n to 2.6.n+1

[aegl]

Several slashdot readers have made comments like "I can easily upgrade from 2.6.n to 2.6.n+1 because not much will have changed".

This is all part of the delusion of version numbers. The changes between releases are only limited by how many can be squeezed into the merge window. With an increasing number of developers, and development tools that seem to be scaling the overall trend seems to be that the n+1 release is progressively more different that its predecessor. Here are the diffstats for the last few kernels:

2.6.15 -> 2.6.16 6721 files changed, 392461 insertions(+), 202469 deletions(-)
2.6.16 -> 2.6.17 6321 files changed, 416664 insertions(+), 308709 deletions(-)
2.6.17 -> 2.6.18 8972 files changed, 381890 insertions(+), 217058 deletions(-)
2.6.18 -> 2.6.19 8040 files changed, 515161 insertions(+), 291784 deletions(-)
2.6.19 -> 2.6.20 5825 files changed, 262475 insertions(+), 136162 deletions(-)
2.6.20 -> 2.6.21 6568 files changed, 319232 insertions(+), 175247 deletions(-)
2.6.21 -> 2.6.22 7620 files changed, 519591 insertions(+), 266699 deletions(-)
2.6.22 -> 2.6.23 7203 files changed, 406268 insertions(+), 339071 deletions(-)
2.6.23 -> 2.6.24 10209 files changed, 776107 insertions(+), 483031 deletions(-)
2.6.24 -> 2.6.25 9738 files changed, 777371 insertions(+), 404514 deletions(-)
2.6.25 -> 2.6.26 8676 files changed, 595389 insertions(+), 416139 deletions(-)

Re:It also reflects...

[Bill_the_Engineer]

The new way is easy.. new features and drivers get added to the latest 2.6.x-rc only and only bug fixes get added to the old kernels.

You do realize that if you substitute 2.6.x-rc with 2.7.x, you are doing the same thing we've been doing when we had the experimental branch.

The only difference is that we no longer have to update the minor number, otherwise we would be on version 2.8 (or higher) by now.

This means that if I want to be sure I'm rock solid I just install the latest patch to the kernel I'm running and I can be sure no one has tried to add new features or drivers that would otherwise destabilize my stuff.

I can see the advantages of the current version number scheme as it relates to the traditional desktop/server user.

But you're lucky enough to not have to compile a driver for a non-mainstream piece of embedded hardware, and have to spend time updating the driver code because something that was probably flagged as deprecated in 2.6.8 was removed completely in 2.6.9. However in the old system, the function would be deprecated in the 2.6 kernel and removed in the 2.8 kernel. Under the old system, a driver marked for the 2.6 kernel would compile without modification, but I would expect to have to update the driver for 2.8.

My point being that both number schemes has its advantages, it just the old system benefited me more. Now if we would tag versions that are considered a production release (like I suggested in my previous post), it would be a good compromise since you would continue to benefit from not having so many forks in the kernel and I would benefit by knowing where the removal of deprecated functions have taken place.