Share your knowledge at the LQ Wiki.
Go Back > Blogs > hazel
User Name


Rate this Entry

All kinds of version numbers

Posted 08-28-2020 at 05:44 AM by hazel

A novice in on of the LQ forums recently complained that he couldn't understand version numbers in Linux. That's not perhaps surprising because software version numbers are used in several different ways, often simultaneously. Every program or library that is in active development goes through different versions as its developer adds features or corrects reported bugs. The Linux kernel is no exception, for it is, after all a program. But over the years, the kernel versioning system has become a lot more complicated than that used for most user-space software.

Linux distributions are also usually tagged with a version number, and some distros use a version name as well. Each version comes as an image that can be downloaded and installed separately and will usually contain a particular kernel version, a particular version of the GNU C library (glibc) and so on. It's no wonder some people get confused!

Let's start with user packages. Such a package might contain a program or a number of closely related programs (often with a built-in library containing code common to them), or a stand-alone library designed to be used for a specific purpose by programs yet unwritten. Or it might be a data package like time zone data, a font family or a set of icons. Whatever it is, it is going to need maintenance and frequent revision. That is why we need version numbers.

Typically these come in a triple format: packagename-n1.n2.n3.
  • n1 is called the major version number. When it increments, this is a sign that the package has been substantially rewritten. In an application, this might mean a visibly different user interface or major additional facilities. In a library, it usually indicates a change in the programming interface, so that programs which use that library need to be rebuilt and sometimes rewritten.
  • n2 is called the minor version number. As you might expect, a change in this number indicates a less substantial change in the code. Often this is the result of consolidating a number of patches (see below). A change in the minor version of a library usually does not require rebuilding of the programs that use it.
  • n3 is called the patch number. A patch is a small change to a program, often made to fix a bug. In the early days of UNIX, when there was no broadband and data travelled slowly, developers would release patches as small text files that were quick and easy to download and could be blended locally into the program source, using a utility called (surprise!) patch. Then the patched program could be rebuilt. But nowadays most distros supply binaries built from the patched source code.

When it comes to the kernel, things are more complicated. When I started out with Linux, the kernel stood at version 2.4. In those days the minor version number told you what kind of kernel you were dealing with. Production kernels (i.e. those suitable for use by ordinary people) had even minor version numbers. An odd number indicated a development kernel which was still being worked on by the kernel hackers. You would be ill-advised to use such a kernel in a working distro.

The development kernel corresponding to 2.4 was 2.5. The idea was that at some point it would be stable enough to be copied/hived off as 2.6. The new development kernel would then become 2.7. Of course each of these would spawn a series of patched kernels with version numbers like 2.4.20.

As the kernel tree became ever larger and more complex, it was recognised that some users, particularly those who ran server machines, needed more stability. So the numbering was rearranged. There is now a developing Main line and numbered versions are hived off from this. Some minor versions, such as 4.19 and 5.4, are designated for long term support (LTS). These are constantly updated with bug and security patches so that they can safely be used for years on a server or in desktop distros that take a conservative attitude to software. The others are supported with patches only until the next minor version comes out.

The result is that the overall version number of a kernel no longer tells you how old it is. An LTS kernel with a high patch number may be more recent than a non-LTS kernel with a higher overall version number which is no longer getting updates. All security fixes get incorporated into the main line so that they will be part of all later kernels but they also get backported into all the currently supported LTS kernels. Older non-LTS kernels don't get these backports.

Occasionally I have known this to cause trouble. At the time of the Meltdown panic, many users were advised to install an LTS kernel that had been patched against Meltdown, because the version that came with their distro was not receiving this patch. But because this new kernel had an older overall version number, the automated scripts that updated the GRUB bootloader placed it in the subsidiary options menu, leaving the previous kernel in the main menu. Fortunately this kind of glitch is fairly easy to fix.

What sometimes causes further confusion is that distros usually have their own version numbers which cut across those used by the software they contain. In particular, newbies may become confused between distro versions and kernel versions, since both get referred to in some contexts simply as "Linux".

Not all distros have versions. Some, like Arch, Gentoo and Debian Unstable (Sid) are rolling releases. Their contents get updated constantly but there is no point at which a new version can be said to exist. Of course every piece of software in these distros (including the kernel) has a version number, but the distro itself doesn't.

Most distros however do have versions which succeed one another, often at fixed intervals. Typically the version numbers are of the form n1.n2, i.e. a major and a minor version number. There is no need of a patch number because the packages inside the distro get patched by the regular updates.

A new major version will be significantly different from its predecessor. A new minor version (often called a point release) will be different enough to justify releasing a new installation image but not every user will want the bother of upgrading at that stage. However it is advisable to upgrade whenever a completely new release comes out, because upgrading seldom goes smoothly if there is a big gap in versions.

Some rapidly-changing distros, notably Ubuntu, now have long term support releases which function in a similar way to those of the kernel. Ubuntu usually has a new release every six months and an LTS release every two years. Users who want stability can use these LTS versions, which will continue to receive updates until the next LTS release comes out.
Views 3577 Comments 0
« Prev     Main     Next »
Total Comments 0




All times are GMT -5. The time now is 01:54 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration