Linux Kernel Release Lifecycle

Linux development follows a time-based cycle around the mainline Git tree maintained by Linus Torvalds. Mainline development, stable backports, and distribution kernels are related but distinct release streams.

Mainline Development #

Most patches move through a hierarchy rather than going directly to Linus. A developer posts a patch to the relevant mailing list; reviewers and a subsystem maintainer evaluate it; the maintainer stages accepted work in a subsystem tree. Lower-level trees can feed higher-level trees, such as a driver tree feeding a networking tree. Integration in linux-next exposes conflicts between subsystem trees before they reach mainline. During the merge window, top-level maintainers send signed pull requests to Linus’s tree.

A mainline release starts an approximately two-week merge window for the next release. Changes merged during that window have generally already been developed, reviewed, and tested. Closing the window produces <major>.<minor>-rc1; subsequent release candidates arrive about weekly while maintainers fix regressions and integration defects. New features are deferred except for unusual low-risk cases. The final release commonly follows -rc7, although serious unresolved defects can require additional candidates. A complete cycle therefore takes about 9–10 weeks.

Release candidates are test snapshots, not stable-update branches. For example, 6.12-rc3 is the third candidate for mainline 6.12, whereas 6.12.3 is the third stable update after the final 6.12 release.

Stable and Long-Term Releases #

After a final mainline release, designated stable maintainers take responsibility for its .y branch. The current stable rules require a fix, or an equivalent fix, to exist in mainline first. A candidate must be tested, obviously correct, no more than 100 lines including context, and address a real user-visible bug or add a device ID. Feature development and cleanup without user benefit do not qualify. Accepted backports pass through a public review cycle before the next <major>.<minor>.<patch> release.

Some stable branches are selected for long-term support. Selection is not encoded in the version number and is not promised for a future release in advance. Maintainer capacity, user and vendor demand, and suitability of the release all influence the choice. Projected end-of-life dates can be extended or shortened because they represent maintenance commitments rather than ABI guarantees.

Distribution vendors can start from a mainline or long-term release, add patches, and publish a different support schedule. Consequently, a string such as 6.12.18-200.fc41.x86_64 identifies a vendor build, not an upstream stable tag.

Version Numbers and End of Life #

Current upstream final releases use <major>.<minor> and stable updates add a third component. The major increment does not indicate an ABI break; kernel.org explains that it is changed when the minor number becomes inconveniently large. The pre-2.6 odd/even development convention is obsolete because -rc now identifies prereleases.

Check the running build with:

uname -r

Local and vendor suffixes in that output are part of the build release string. Compare the underlying upstream version with Git tags rather than ordering arbitrary suffixes as though they were upstream patch numbers.

The kernel.org releases page is authoritative for active mainline, stable, and long-term series, their maintainers, and projected end-of-life dates. Once a series reaches end of life, upstream no longer issues fixes for it; continued use requires a vendor maintenance commitment or migration to a supported series.

Source References #

• How the development process works documents the merge window, release candidates, maintainer hierarchy, and linux-next.
• Stable kernel rules defines backport acceptance and review.
• Kernel releases publishes current release status and end-of-life projections.