PREV_LEC | NEXT_LEC

What You Will Learn

Prerequisites

This lecture builds directly on lecture 2’s coverage of version numbers and the mainline release cycle — read that first if you have not already.

Why Mainline Alone Is Not Enough

Mainline development moves forward only — once 6.9 releases, all fixes for it land in 6.10, not backported into 6.9 itself, because Linus and the subsystem maintainers have already moved on to the next merge window. That works fine for a desktop that upgrades every few months, but it breaks down completely for an embedded product that gets certified once and then ships unchanged for years. A router or a medical device cannot “just upgrade to the newest kernel” every time a bug surfaces, yet it absolutely still needs security and stability fixes for the version it shipped with.

The kernel project solves this with a second layer of maintenance that runs in parallel to mainline development.

Once a version such as 6.9 is tagged, it hands off from “mainline” to “stable.” Every subsequent bug or security fix that lands in mainline gets evaluated for backporting, and if accepted, ships as a stable point release with a third number appended: 6.9.1, 6.9.2, and so on. A small subset of releases are additionally designated LTS, meaning the stable team commits to backporting fixes to them for a much longer window — long enough to realistically cover an embedded product’s certification and field lifetime.

Fetching A Specific Stable Or LTS Version

The stable tree lives in its own repository, separate from Linus’ mainline tree. Clone it the same way, over HTTPS:

$ git clone --depth 1 --branch v6.6.30 \
    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git ep-board-kernel
$ cd ep-board-kernel
$ git describe --tags
v6.6.30

Cloning with --branch and --depth 1 together fetches only that exact tag’s history, which is far faster than cloning everything and checking out afterward. If you already have a full clone, checking out a different point release is a single command:

$ cd linux-stable
$ git fetch --tags
$ git checkout v6.6.31

Confirming What You Actually Have

Before you hand a kernel source tree off to a build system, it is worth confirming it really is the tagged version you expect rather than trusting a directory name:

$ make kernelversion
6.6.31
$ git log -1 --format='%H %cd' --date=short
a1b2c3d4e5f6... 2024-06-12

Real-World Use Case

A team building an industrial gateway with a five-year field lifetime chooses an LTS line such as 6.6, not the newest mainline release, precisely so that their vendor and the upstream stable team keep shipping security patches for years without the team having to rebase their board support package onto a new major kernel mid-product-life. When a CVE is announced, they simply pull the latest 6.6.x tag rather than evaluate a jump to 6.9 or 6.12.

Common Mistakes

• Shipping a random non-LTS stable point release (for example a “6.7.x” that never received an LTS designation) and discovering a year later that no further security fixes are coming.
• Manually cherry-picking individual upstream fixes onto an old kernel instead of simply advancing to the next available point release on the same LTS line.
• Confusing “stable” (the short-lived maintenance branch every release gets) with “LTS” (the small subset that gets multi-year support) — they are not the same commitment.

Best Practices

• For any product with more than a one-year field lifetime, default to the current LTS line rather than the latest mainline release.
• Track the official kernel.org releases page so you know when your chosen LTS line is nearing its end-of-life window and plan the next migration early.

Security Consideration

Staying on an LTS line only helps if you actually pull new point releases. An embedded device frozen on 6.6.1 forever gets none of the security benefit of choosing LTS in the first place — the safety comes from the ongoing backported fixes, not from the LTS label itself.

Summary

Mainline development only ever moves forward, so the stable and LTS trees exist to backport fixes onto already-released versions — stable for a short window after every release, LTS for a much longer window on a chosen few. For any embedded product with a multi-year lifetime, picking an LTS line and actually tracking its point releases is the standard, low-drama way to stay both stable and secure. That closes out this chapter’s introduction to kernel versioning; the next chapter moves on to actually configuring and building a kernel image.

FAQ

PREV_LEC | NEXT_LEC