Understanding the Linux Kernel Versioning Scheme

If you’ve been a Linux user for a long time, you’d know that Linux distributions have unique versions and each version has a specific codename. The Linux kernel also has different version numbers, which act as an identifier for the series the kernel belongs to. However, there’s a difference between how kernel versions were formed earlier and how Linus Torvalds names them now.

By the end, you’ll be more familiar with the Linux kernel versioning scheme and will feel more comfortable reading kernel version numbers and identifying the various features associated with a specific release.

The Traditional Linux Kernel Versioning

When Linus first started developing the kernel, the versioning system used simply consisted of an incrementing variable scheme starting with zero (0.x). Initially, Linus was the only one working on the project, and this versioning system sufficed the need to document and distribute new kernel releases.

Here are some of the kernel releases that followed this naming scheme:

Later on, as more developers started contributing to the project and the number of revisions and patches increased significantly, it was decided that this versioning scheme wasn’t suitable for software such as a kernel. And starting from version 1.0, Linus adopted a new scheme with a few additional variables.

Introduction of a More Descriptive Versioning System

In 1994, with the release of Linux kernel 1.00, Linus started using a new versioning system that employed three variables in the syntax: “a.b.c“. These variables (a, b, and c) represent the major release, minor release, and revision number for the specific kernel release, respectively.

Take Linux kernel 1.1.95 as an example. You can decode it as the first major release, first minor release, and 95th revision.

At the time, even minor version numbers denoted stable kernel releases, while odd ones represented development releases. It was important to have separate branches so that developers could add and test new features in the kernel without affecting the stable branch.

Kernel developers add and improve new features in the development branch until it gets stable enough to be released as an LTS kernel. The LTS kernel 3.2 was developed by stabilizing the new features in version 3.1, and similarly, a new development kernel 3.3 branched out of 3.2 to make way for new features that would be then introduced in Linux 3.4.

Starting from Linux kernel 2.4, a fourth variable in the kernel name denoted the patch releases. You can say that version 2.4.37.10 is the tenth patch release for kernel 2.4.37.

Up until Linux 2.6, this versioning system was used, and it was effective in distinguishing a specific version from others. Adding revision counts and patch releases in the version number was descriptive, but it meant having lengthier and more complex kernel versions. And yet again, a new and better scheme was required.

How Are Linux Kernel Versions Named Now?

With Linux version 3.0, Linus dropped the fourth variable from the version number. Now, the kernel version is formed according to the syntax: a.b.c, where a, b, and c are the major release, minor release, and revision count, respectively. This versioning scheme is similar to the one used between the 1.0 and 2.4 kernel releases.

Due to advancements in version control systems, contributors could now seamlessly work on stable branches and add new features without accidentally busting the already-working, stable releases. Therefore, the usage of even and odd minor version numbers for stable and production branches of the kernel became superfluous after the introduction of kernel version 4.0, and the first LTS release (4.1) in the 4.x series had an odd minor version number.

You might also notice some characters at the end of the version number, like rcX. Review candidates (or “rc” for short) are preview releases and pre-patch versions of the kernel that the developers need to patch to remove bugs and other issues. These are a replacement for the development releases that were previously denoted by an odd minor version number.

Although these releases are specifically reserved for kernel developers so they can fix the reported issues and implement new features, you can also download and test these kernel review candidates if you want, but it’s generally not recommended considering this is where most of the development happens. The latest preview version of the kernel at the time of this writing is 5.19-rc6.

To create new versions, the preceding variable is incremented when the value of a variable reaches a specific number. For example, the major version is updated to the next digit whenever the minor version count gets close to 20.

Linus mentioned in his 5.0 kernel development mail that he simply updated the major number to five because the minor release count got too large to count on fingers and toes (20!). Similarly, according to kernel.org, the major version number is incremented when the number after the first dot starts looking “too big.” The final kernel version in the 3.x series was 3.19 and the last major 4.x kernel series was 4.20, which was then bumped up to 5.0.

Since version 3.0, the Linux kernel has been following this versioning scheme and it has proved to be efficient for as long as three major kernel releases (versions 3.x, 4.x, and 5.x).

Identifying a Linux Kernel Release Using Version Numbers

Considering the sheer number of Linux kernel versions released, there’s a need for a proper system to identify and differentiate a specific version from the others. With the new kernel versioning scheme, kernel versions can now be effectively identified and compared, and it’s easy to know which kernel version is the latest and which one was released earlier.

If you want to check the Linux kernel version currently installed on your system, you can do that using uname, a Linux command that lets you list system-related information. Depending on the distro you’re running, the version number displayed by uname might be different than actual Linux kernel versions.