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 !
seems unnecessary, as it appears to be more or less a static website.
True, but it can be intercepted easily with HTTP. Integrity of the data while in transit can’t be assured.
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.
Are we sure about that? LOL
The Linux kernel numbering scheme works well enough. It’s a sign post for features. People can say feature X appeared in version 6.10, but was deprecated in 6.12 because the dev was an asshat.
Let’s bring in OpenBSD and how their number scheme doesn’t make any sense either. or web browsers which have an eternally incrementing number for a version that doesn’t mean anything at all. Solaris 11.2 U6, what does this even mean. Then there is MS and their wonderful naming conventions. NT 4.5 SP6.3, or something, Windows XP. Let’s not talk about referring to software by code names.
Much like gender, software versions are a construct of society and absolutely meaningless. It means what ever the project says it means.
Because math is hard. 1 is less then 2 is pretty easy to figure out.
Personally, timestamping a kernel make less sense then the arbitrary numbering system we have now. Timestamping log files makes sense because it’s contextual information, but I don’t need to know when my kernel was compiled. I just need to know 1 < 2.
Flatland_Spider,
Well, you wouldn’t loose that with dates. Also, dates are not arbitrary, they actually do mean something, which not only can help indicate how stale something is but also facilitates relative comparisons with other software without having to look up version histories on wikipedia – just the other day I was looking up the dates that corresponded to java and linux versions. Instead of having to remember multiple facts (ie date AND version numbers), one fact can represent both. It could be even more useful on things like routers where you might otherwise lack a version/date map.
If a project doesn’t meaningfully use major/miner version numbers, then using dates to convey more information while being less arbitrary seems like a logical improvement.