Right, let’s talk about version numbers. You’d think this would be the easy part, wouldn’t you? A simple, logical numbering scheme. Bless your heart. The kernel developers are brilliant engineers, not marketing majors, and it shows in their versioning system, which has had more plot twists than a daytime soap opera.

First, the format: A.B.C. A is the major version, B was the minor version, and C is the patch/revision level. I say “was” because the whole meaning of B changed back in 2011 with the release of kernel 3.0. Before that, an even B (e.g., 2.6) meant a “stable” series, and an odd B (e.g., 2.7) meant a “development” series. They abandoned that when the minor numbers started getting too high. Linus Torvalds jokingly said he ran out of fingers and toes to count on. So now, we just increment the major number every so often when Linus gets a feeling in his bones that it’s time. There’s no deeper meaning to 4, 5, or 6; it’s just a counter. The real information is in the C, and the suffixes.

Mainline: Where the Magic (and the Mayhem) Happens

This is Linus Torvalds’s tree. It’s the bleeding edge. Every single change, feature, driver, and—yes—bug, gets merged here first. New versions are released roughly every 9-10 weeks. You do not run a mainline kernel on anything you care about unless you are a kernel developer, a masochist, or testing something very specific. It’s the integration branch where all the new stuff gets thrown into the pot and stirred vigorously. It’s unstable by definition. You track mainline to see what’s coming down the pipe, to test new hardware support, or to contribute patches. To get the latest mainline code, you’d clone Linus’s tree:

git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Stable: The Bug Fix Backport Brigade

This is where Greg Kroah-Hartman and the stable team perform what can only be described as minor miracles. Once a mainline kernel is released (say, 6.9), that release becomes the base for the stable series (6.9.y). The stable team then backports fixes from mainline to this series. Crucially, they only backport fixes for bugs—no new features, no breaking changes. This is what your distribution uses as a base. You should be running a stable kernel.

The y in 6.9.y gets incremented with each set of bugfix releases. You can see all the stable branches on kernel.org. To get the latest stable fixes for 6.9, you’d do:

git clone -b linux-6.9.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

A common pitfall? Assuming “stable” means “perfect.” It doesn’t. It means “more stable than mainline.” A fix backport can sometimes introduce a new, subtle bug on its own (a “regression”), which is why you don’t automatically jump on every single .y release. Let your distribution’s testing pipeline be your guide.

Long Term Support (LTS): The Anchors

Some kernels are designated as Long Term Support (LTS) kernels. This is for people and organizations—factories, embedded systems, large server farms—that need to run a single kernel version for years without major upgrades. An LTS kernel (e.g., 6.6) is a specific stable release that gets picked and then receives backported fixes for a much longer period, usually for two years, but often extended to six or more. There are usually several LTS kernels supported at any given time.

This is a godsend for maintainability. The list of currently supported LTS kernels is curated by the kernel.org folks. You can always find it. The key here is that you’re trading new features and sometimes newer hardware support for immense stability and predictability.

Decoding Your Current Kernel

So, what are you running right now? The uname -r command is your friend. Let’s break down a typical output:

$ uname -r
6.6.21-1-lts

This tells us we’re on major version 6, the base release was the 6.6 mainline kernel, it’s been updated to the 21st revision of the stable patch set, and someone (in this case, the Arch Linux packagers) has appended their own suffix (-1-lts) to indicate it’s their build of the LTS kernel. The -lts suffix is a courtesy label; the fact that it’s 6.6.y is what truly marks it as an LTS kernel. If you see arch or generic or something else, that’s just your distribution’s way of marking their specific build configuration.

The best practice? Unless you have a compelling reason to do otherwise, stick with whatever stable kernel your distribution provides. If you need long-term reliability, opt for their LTS option. And only venture into mainline if you’re prepared to be an active participant in the development process, not a passive consumer. The kernel is a fascinating, living project, and its versioning scheme, quirks and all, reflects that perfectly.