Greg K-H Recommends New Kernel Version Naming
Greg Kroah-Hartman, Linux developer at Novell, suggests a new naming scheme for the Kernel releases on the Kernel mailing list. The four-digit year would be included in the name.
Kroah-Hartman writes that he had meant to bring up his suggestion at the Kernel Summit 2008 in September that he does now as a follow-up. He had always been involved with version numbering and finds the current scheme unmanageable.
His recommendation: future versions of the Linux kernel should follow the pattern four_digit_year.release_number.minor_release_number. By this pattern the first release in the coming year would be 2009.0.0, the second 2009.1.0, and so forth. If zero-numbered releases are undesirable, he says, the year could also begin with release 2009.1.1.
Kroah-Hartman points out that the naming scheme provides a better way to determine how old the release is. Kernel 2004.9.0 would be easier to date than Kernel 2.6.9.
The current scheme follows the pattern 2. major_release.minor_release.extra_version. With the new scheme, kernel macros with major and minor numbers would also have compatible naming so as not to break scripts, he assures the community in his email.
Among the first responses was one from H. Peter Anvin who found it easiest just to increment the last digit, such as 27, 28, 29, etc. He finds the existing prefix 2 with the large following digits to have "outlived its utility" and suggests bumping the version to 3.0 and maintaining that scheme for "huge changes."
Adrian Bunk had rather a different view and warned against radical changes that could affect not only the Kernel and its tools, but break countless userspace programs. Many of these programs interpret the kernel version number through calls such as uname -r. He gives a snippet from an OpenSSL library script as an example.
Comments
comments powered by DisqusSubscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
![Learn More](https://www.linux-magazine.com/var/linux_magazin/storage/images/media/linux-magazine-eng-us/images/misc/learn-more/834592-1-eng-US/Learn-More_medium.png)
News
-
NVIDIA Released Driver for Upcoming NVIDIA 560 GPU for Linux
Not only has NVIDIA released the driver for its upcoming CPU series, it's the first release that defaults to using open-source GPU kernel modules.
-
OpenMandriva Lx 24.07 Released
If you’re into rolling release Linux distributions, OpenMandriva ROME has a new snapshot with a new kernel.
-
Kernel 6.10 Available for General Usage
Linus Torvalds has released the 6.10 kernel and it includes significant performance increases for Intel Core hybrid systems and more.
-
TUXEDO Computers Releases InfinityBook Pro 14 Gen9 Laptop
Sporting either AMD or Intel CPUs, the TUXEDO InfinityBook Pro 14 is an extremely compact, lightweight, sturdy powerhouse.
-
Google Extends Support for Linux Kernels Used for Android
Because the LTS Linux kernel releases are so important to Android, Google has decided to extend the support period beyond that offered by the kernel development team.
-
Linux Mint 22 Stable Delayed
If you're anxious about getting your hands on the stable release of Linux Mint 22, it looks as if you're going to have to wait a bit longer.
-
Nitrux 3.5.1 Available for Install
The latest version of the immutable, systemd-free distribution includes an updated kernel and NVIDIA driver.
-
Debian 12.6 Released with Plenty of Bug Fixes and Updates
The sixth update to Debian "Bookworm" is all about security mitigations and making adjustments for some "serious problems."
-
Canonical Offers 12-Year LTS for Open Source Docker Images
Canonical is expanding its LTS offering to reach beyond the DEB packages with a new distro-less Docker image.
-
Plasma Desktop 6.1 Released with Several Enhancements
If you're a fan of Plasma Desktop, you should be excited about this new point release.
Age of release
Even better would be YYYY.MM.1.
nice idea but,
most sensible out of all
Though I'm one of those who really thinks that changing now kernel versioning provides little to no gains.
To me it more and more sounds like lots of people are bothered by visibly smaller role kernel now is playing in the whole "Linux OS" thing. Seems like people want some shake up of kernel development to make their contributions look more significant.
I see the flame war starting...