If you’re old enough, you no doubt remember that up until the 2.6.0 release of the Linux kernel, an odd number after the first version number indicated a pre-release, development version of the kernel. Even though this scheme was abandoned with the 2.6.0 release in 2003 and since then every single release has been a stable release, it seems the ghosts of this old versioning scheme still roam the halls, because prominent Linux kernel developer Greg Kroah-Hartman just published an explainer about Linux kernel versions.
Despite having a stable release model and cadence since December 2003, Linux kernel version numbers seem to baffle and confuse those that run across them, causing numerous groups to mistakenly make versioning statements that are flat out false. So let’s go into how this all works in detail.
↫ Greg Kroah-Hartman
I genuinely find it difficult to imagine what could possibly be unclear about Linux kernel version numbers. The Linux kernel uses a very generic major.minor scheme, but that’s not where the problems lie – it’s the actual development process of each of these numbered release that’s a bit more complex. This is where we have to talk about things like the roughly 10-week release cycle, containing a 2-week merge window, as well as Torvalds handing off the stable branch to the stable kernel maintainers.
The other oddity is when the major version number gets incremented – the first number in the version number. There’s no real method to this, as Kroah-Hartman admits Torvalds increments this number whenever the remaining numbers get too high and unwieldy to deal with. Very practical, but it does mean that going from, say, 5.x to 6.x doesn’t really imply there’s any changes in there that are any bigger or more disruptive than when going from 6.8.x to 6.9.x or whatever.
There’s a few more important details in here, of course, like where LTS releases come from, but that’s really it – nothing particularly groundbreaking or confusing.
I don’t know for linux, but rumor says this is how microsoft chooses its version numbers….
https://www.youtube.com/playlist?list=PLSVSkEPm4yRNjHjpe3JtdY6wVyrF_FjXd
Sysau,
What am I watching?? Haha. I’ve seen some of their other sketches, British comedy is something!
The dave and mitchell look, a sketch show.
Major version gets bumped when Linux runs out of fingers and toes. Nothing arbitrary about that.
https://lkml.org/lkml/2019/1/6/178
Greg’s site is http, not https ? In 2025 ? With 10years of letsencrypt behind !? Com’on !
Thom Holwerda,
It’s not that anybody thinks the numbering scheme itself is confusing, most projects tie this scheme to milestones and compatibility, but not linux. Instead the rational of what makes up a major and minor version is decided arbitrarily. To this end I think the critics are right, it is confusing for Torvalds to arbitrarily decide whether to bump up this number versus that number, and have him explicitly tell us it’s arbitrary. Why not just go with a date based scheme instead. Again it’s not the numbering scheme itself that’s confusing, but the rational behind using a scheme that doesn’t align with expectations.
Think of a document with numbered lists/contents (ie 2.5.8), but instead of being broken up into logical sections and subsections, the author just decided “Hell with it, I’m going to disconnect the numbers from the content and bump up the numbers whenever” – not matching people’s expectations of how numbering schemes normally work is unnecessarily confusing.
> Why not just go with a date based scheme instead.
Remember how stuff randomly broke when 2.6.X became 3.X ?
Right now we still have 62 releases before checks expecting a single digit major version break…
Serafean,
I don’t remember anything breaking, what’s an example?
Edit: Just to be clear, I’ve experienced things breaking on linux obviously. The non-stable kernel ABI has routinely broken out of tree drivers. …but I can’t think of something that broke specifically because of the version numbers.