Think of linux-next as a large staging area. Every subsystem in the kernel — networking, filesystems, drivers, sound, and so on — is maintained by a different person called a subsystem maintainer. Before those changes get merged into the official kernel, they are all collected together in the linux-next tree for early testing.

This tree can and does break at any time. It is not meant for end users or product developers. If you are an upstream kernel contributor trying to send patches, this is where your work eventually lands before going to Linus Torvalds.

After Linus Torvalds opens the “merge window” for about two weeks, he then closes it and starts publishing release candidates. You will see versions like 6.10-rc1, 6.10-rc2 and so on. These are pre-release test kernels.

Usually 6 to 8 release candidates are published before the final stable release. Testers run these on spare machines to find bugs early. If you spot a regression (something that worked before but broke now), reporting it is one of the most valuable contributions you can make to the community.

These are the official, released kernels from kernel.org. Once testing is done with the RC kernels, Linus publishes the stable release — for example, 6.10. After that, this version receives only bug fixes and security patches for a few months, until the next stable version ships.

Stable kernels are also called vanilla kernels because they are pure and unmodified by any vendor. Most Linux distributions take a stable kernel and then apply their own extra patches on top.

Distribution kernels are the kernels that come bundled with Linux distributions like Ubuntu, Fedora, or Debian. They always start from a stable or LTS vanilla kernel but then have extra patches applied by the distro team — things like driver backports, hardware enablement, and security hardening.

LTS (Long Term Support) kernels are the real deal for anyone doing serious work. Once a year or so, one particular stable kernel is selected to be an LTS kernel. That kernel then receives bug fixes and security patches for 2 to 6 years instead of just a few months. This is exactly what embedded Linux products, Android devices, routers, and industrial systems are built on.

Some industries cannot afford to change their kernel every few years. Think about a railway signalling system, a power grid controller, or medical equipment. These devices run for 10, 15, even 20 years. For these use cases, the Civil Infrastructure Platform (CIP), a Linux Foundation project, selects specific kernels as Super LTS releases.

As an example, the Linux 4.4 kernel (the 16th LTS release) was the first kernel chosen for SLTS. It is planned to receive support until at least 2026, and possibly until 2036 — that is over two decades of support for a single kernel version.

A stable kernel receives bug fixes and security patches for a few months until the next stable release ships. An LTS kernel is a specific stable kernel that has been selected for long-term maintenance — it receives patches for 2 to 6 years. For any project with a long lifecycle, LTS is always preferred because you get continued security support without upgrading to a completely new kernel.

The linux-next tree is a staging area that collects patches from all kernel subsystem maintainers before they are merged into the mainline kernel. It represents the bleeding edge of kernel development. It is used by kernel developers and contributors who are working on upstream patches. It is not suitable for production systems because it can break at any time.

I would choose an LTS kernel, ideally the most recent one with the longest EOL date. LTS kernels receive security patches and critical bug fixes for up to 6 years, which covers most of the product’s field life. If the lifecycle extends beyond that, I would evaluate an SLTS kernel from the Civil Infrastructure Platform, which can provide support until 2036 for qualifying projects.

A vanilla kernel is the pure, unmodified kernel source from kernel.org, maintained by Linus Torvalds and the kernel community. A distribution kernel starts from a vanilla base but has additional patches applied by the distro team — these include backported drivers, hardware enablement patches, and distro-specific security hardening. For kernel development and learning, vanilla is preferred because it does not have any hidden vendor-specific modifications.

Multiple LTS kernels can be active and maintained in parallel at the same time. This is intentional because different products and platforms are built on different kernel versions. A product that shipped in 2020 may be running the 5.4 LTS kernel, while a newer product may use the 6.6 LTS kernel. Both receive patches simultaneously so that all active products remain secure without being forced to do a major kernel upgrade.