Linux kernel stable versions

Which Linux Kernel Version Is ‘Stable’?

Almost every time Linus Torvalds releases a new mainline Linux kernel , there’s inevitable confusion about which kernel is the “stable” one now. Is it the brand new X.Y one, or the previous X.Y-1.Z one? Is the brand new kernel too new? Should you stick to the previous release?

The kernel.org page doesn’t really help clear up this confusion. Currently, right at the top of the page. we see that 4.15 is the latest stable kernel — but then in the table below, 4.14.16 is listed as “stable,” and 4.15 as “mainline.” Frustrating, eh?

Unfortunately, there are no easy answers. We use the word “stable” for two different things here: as the name of the Git tree where the release originated, and as indicator of whether the kernel should be considered “stable” as in “production-ready.”

Due to the distributed nature of Git, Linux development happens in a number of various forked repositories . All bug fixes and new features are first collected and prepared by subsystem maintainers and then submitted to Linus Torvalds for inclusion into his own Linux tree , which is considered the “master” Git repository. We call this the “ mainline ” Linux tree.

Release Candidates

Before each new kernel version is released, it goes through several “release candidate” cycles, which are used by developers to test and polish all the cool new features. Based on the feedback he receives during this cycle, Linus decides whether the final version is ready to go yet or not. Usually, there are 7 weekly pre-releases, but that number routinely goes up to -rc8, and sometimes even up to -rc9 and above. When Linus is convinced that the new kernel is ready to go, he makes the final release, and we call this release “stable” to indicate that it’s not a “release candidate.”

Bug Fixes

As any kind of complex software written by imperfect human beings, each new version of the Linux kernel contains bugs, and those bugs require fixing. The rule for bug fixes in the Linux Kernel is very straightforward: all fixes must first go into Linus’s tree. Once the bug is fixed in the mainline repository, it may then be applied to previously released kernels that are still maintained by the Kernel development community. All fixes backported to stable releases must meet a set of important criteria before they are considered — and one of them is that they “must already exist in Linus’s tree.” There is a separate Git repository used for the purpose of maintaining backported bug fixes, and it is called the “ stable ” tree — because it is used to track previously released stable kernels. It is maintained and curated by Greg Kroah-Hartman.

Latest Stable Kernel

So, whenever you visit kernel.org looking for the latest stable kernel, you should use the version that is in the Big Yellow Button that says “Latest Stable Kernel.”

Ah, but now you may wonder — if both 4.15 and 4.14.16 are stable, then which one is more stable? Some people avoid using “.0” releases of kernel because they think a particular version is not stable enough until there is at least a “.1”. It’s hard to either prove or disprove this, and there are pro and con arguments for both, so it’s pretty much up to you to decide which you prefer.

On the one hand, anything that goes into a stable tree release must first be accepted into the mainline kernel and then backported. This means that mainline kernels will always have fresher bug fixes than what is released in the stable tree, and therefore you should always use mainline “.0” releases if you want fewest “known bugs.”

On the other hand, mainline is where all the cool new features are added — and new features bring with them an unknown quantity of “new bugs” that are not in the older stable releases. Whether new, unknown bugs are more worrisome than older, known, but yet unfixed bugs — well, that is entirely your call. However, it is worth pointing out that many bug fixes are only thoroughly tested against mainline kernels. When patches are backported into older kernels, chances are they will work just fine, but there are fewer integration tests performed against older stable releases. More often than not, it is assumed that “previous stable” is close enough to current mainline that things will likely “just work.” And they usually do, of course, but this yet again shows how hard it is to say “which kernel is actually more stable.”

So, basically, there is no quantitative or qualitative metric we can use to definitively say which kernel is more stable — 4.15 or 4.14.16. The most we can do is to unhelpfully state that they are “differently stable.”

Learn more about Linux through the free “Introduction to Linux” course from The Linux Foundation and edX.

Источник

Active kernel releases

There are several main categories into which kernel releases may fall:

Prepatch Prepatch or «RC» kernels are mainline kernel pre-releases that are mostly aimed at other kernel developers and Linux enthusiasts. They must be compiled from source and usually contain new features that must be tested before they can be put into a stable release. Prepatch kernels are maintained and released by Linus Torvalds. Mainline Mainline tree is maintained by Linus Torvalds. It’s the tree where all new features are introduced and where all the exciting new development happens. New mainline kernels are released every 9-10 weeks. Stable After each mainline kernel is released, it is considered «stable.» Any bug fixes for a stable kernel are backported from the mainline tree and applied by a designated stable kernel maintainer. There are usually only a few bugfix kernel releases until next mainline kernel becomes available — unless it is designated a «longterm maintenance kernel.» Stable kernel updates are released on as-needed basis, usually once a week. Longterm There are usually several «longterm maintenance» kernel releases provided for the purposes of backporting bugfixes for older kernel trees. Only important bugfixes are applied to such kernels and they don’t usually see very frequent releases, especially for older trees.

Longterm release kernels

Version	Maintainer	Released	Projected EOL
6.1	Greg Kroah-Hartman & Sasha Levin	2022-12-11	Dec, 2026
5.15	Greg Kroah-Hartman & Sasha Levin	2021-10-31	Oct, 2026
5.10	Greg Kroah-Hartman & Sasha Levin	2020-12-13	Dec, 2026
5.4	Greg Kroah-Hartman & Sasha Levin	2019-11-24	Dec, 2025
4.19	Greg Kroah-Hartman & Sasha Levin	2018-10-22	Dec, 2024
4.14	Greg Kroah-Hartman & Sasha Levin	2017-11-12	Jan, 2024

Distribution kernels

Many Linux distributions provide their own «longterm maintenance» kernels that may or may not be based on those maintained by kernel developers. These kernel releases are not hosted at kernel.org and kernel developers can provide no support for them.

It is easy to tell if you are running a distribution kernel. Unless you downloaded, compiled and installed your own version of kernel from kernel.org, you are running a distribution kernel. To find out the version of your kernel, run uname -r :

# uname -r 5.6.19-300.fc32.x86_64

If you see anything at all after the dash, you are running a distribution kernel. Please use the support channels offered by your distribution vendor to obtain kernel support.

Releases FAQ

Here are some questions we routinely receive about kernel release versions. See also the main «FAQ» section for some other topics.

When is the next mainline kernel version going to be released?

Linux kernel follows a simple release cadence:

• after each mainline release, there is a 2-week «merge window» period during which new major features are introduced into the kernel
• after the merge window closes, there is a 7-week bugfix and stabilization period with weekly «release candidate» snapshots
• rc7 is usually the last release candidate, though occasionally there may be additional rc8+ releases if that is deemed necessary

So, to find the approximate date of the next mainline kernel release, take the date of the previous mainline release and add 9-10 weeks.

What is the next longterm release going to be?

Longterm kernels are picked based on various factors — major new features, popular commercial distribution needs, device manufacturer demand, maintainer workload and availability, etc. You can roughly estimate when the new longterm version will become available based on how much time has elapsed since the last longterm version was chosen.

Why are some longterm versions supported longer than others?

The «projected EOL» dates are not set in stone. Each new longterm kernel usually starts with only a 2-year projected EOL that can be extended further if there is enough interest from the industry at large to help support it for a longer period of time.

Does the major version number (4.x vs 5.x) mean anything?

No. The major version number is incremented when the number after the dot starts looking «too big.» There is literally no other reason.

Does the odd-even number still mean anything?

A long time ago Linux used a system where odd numbers after the first dot indicated pre-release, development kernels (e.g. 2.1, 2.3, 2.5). This scheme was abandoned after the release of kernel 2.6 and these days pre-release kernels are indicated with «-rc».

Other resources

Social

This site is operated by the Linux Kernel Organization, Inc., a 501(c)3 nonprofit corporation, with support from the following sponsors.

Источник

Linux kernel version history

This article documents the version history of the Linux kernel. The Linux kernel is a free and open-source, monolithic, Unix-like operating system kernel. It was conceived and created in 1991 by Linus Torvalds.

Linux kernels have different support levels depending on the version. Usually, each stable version continues to backport bug fixes from the mainline until the next stable version is released. However, if a stable version has been designated as a long-term support (LTS) kernel, it will be maintained for an extra few years. After that, versions designated as Super-Long-Term Support (SLTS) will then be maintained by the Civil Infrastructure Platform (CIP) for many more years.

Releases 6.x.y

Releases 5.x.y

• Initial support for LoongArch
• Support for Big TCP
• More secure encrypted virtualization with AMD SEV-SNP and Intel TDX
• Armv9 Scalable Matrix Extension support
• Introduce Intel In-Field Scan driver to run targeted low level diagnostics outside of the CPU’s architectural error detection capabilities
• a.out support removed

• Support for Indirect Branch Tracking on Intel CPUs
• User events
• fprobe, for probing multiple functions with a single probe handler
• Headers rearchitecturing preparations for faster compilation times
• Stricter memcpy() compile-time bounds checking
• Switch to C11

• BPF CO-RE support
• Random number generator improvements
• New Real-Time Linux Analysis (RTLA) tool
• Support giving names to anonymous memory
• Mitigate straight-line speculation attacks

• New futex_waitv() system call for faster game performance
• Memory folios infrastructure for a faster memory management
• Add support for AMX instructions
• Improve write congestion

• New NTFS file system implementation
• ksmbd, an in-kernel SMB 3 server
• Migrate memory pages to persistent memory in lieu of discard
• DAMON, a data access monitor
• Introduce process_mrelease(2) system call

• Ubuntu 22.04 LTS,
• Slackware 15,
• UEK 7

3rd SLTS release (which CIP is planning to support until January 2031); 5.10.19 is named Dare mighty things

5.4-rc5 is named Kleptomaniac Octopus

Источник