The Linux Kernel Release Cycle and How LTS Versions Are Chosen

The Linux kernel follows one of the most predictable schedules in open source: a two-week merge window, around seven release candidates, and a final release roughly every nine to ten weeks. One release each year is promoted to longterm (LTS) status and maintained for years afterwards, which is what distributions build their own support commitments on. This article walks through the cycle, the different kernel series on kernel.org, and how to decide which kernel line to track.

A schedule measured in weeks, not features

The Linux kernel does not have a roadmap of promised features. It has a clock. Every release follows the same shape, and the content of a release is simply whatever was ready when the merge window opened.

Occasionally an eighth release candidate is needed, which pushes the release out by a week. That is the only real source of variation, and it is why a kernel release is usually described as “roughly every nine to ten weeks” rather than a fixed date.

Version numbers carry no meaning

Kernel version numbers are deliberately uninformative. The jump from 2.6 to 3.0, from 3.19 to 4.0, from 4.20 to 5.0 and from 5.19 to 6.0 happened because the minor number grew large enough to be awkward, not because of any architectural break. There is no semantic versioning here: 6.12 is not more significant than 6.11, it is simply the next one.

This matters when reading vendor documentation. A distribution advertising “kernel 6.12” is telling you which upstream release it forked from, not how much has been backported into it.

The kernel series on kernel.org

Several lines are published at any one time:

• mainline - Linus Torvalds’ tree, where the merge window and release candidates happen.
• stable - the most recent release plus a short tail of bug fixes, maintained for a few weeks.
• longterm (LTS) - selected releases maintained for years.
• linux-next - an integration tree where subsystem changes are tested together before the merge window opens. Not intended for production use.

How longterm kernels are chosen

Roughly once a year, usually towards the end of the calendar year, one release is designated longterm. The choice is made by the stable maintainers, taking into account which version the major distributions and embedded vendors intend to ship, since those are the organisations that will contribute testing and fixes.

Recent longterm kernels include 5.10, 5.15, 6.1, 6.6 and 6.12, each announced at the end of its release year.

The maintenance period is not fixed. It was historically six years for some lines, but the stable maintainers reduced the default window for newer LTS kernels, noting that very long tails consume maintainer time without corresponding testing from the companies relying on them. Windows are extended when there is demonstrated industry commitment, so the published end date for a given LTS kernel can change.

What actually lands in a release

A typical kernel release contains on the order of ten to fifteen thousand changesets from well over a thousand developers. The bulk of it is drivers and architecture support rather than core changes, which is why most releases look unremarkable in a changelog but matter a great deal if you have the hardware in question.

Longer-running themes visible across recent releases include Rust support for writing drivers, continued work on the BPF subsystem, scheduler refinements, and filesystem work in Btrfs, XFS and bcachefs.

Which kernel should you run

For most people the answer is: the one your distribution ships.

• Enterprise distributions such as RHEL and SUSE pick one upstream kernel and backport fixes into it for a decade. The version number stays low while the content diverges substantially from upstream.
• Ubuntu LTS ships a kernel from a recent LTS line and offers newer hardware-enablement kernels for those who need them.
• Rolling distributions such as Arch and openSUSE Tumbleweed track mainline closely, usually within days or weeks of a release.
• Running mainline directly makes sense for kernel development, for very new hardware, or when you need a fix that has not been backported yet.

The practical rule: choose an LTS kernel if you value stability and a long patch tail, and mainline if you need recent hardware support and can absorb the upgrade churn.

Conclusion

The kernel’s cadence is the metronome the rest of the Linux world runs on. A merge window, seven or eight release candidates, a release every nine or ten weeks, and one longterm kernel chosen each year. Knowing which line you are on, and what its maintenance window actually is, is more useful than knowing which version number is highest.