Types of Linux Kernel Source Trees
LTS, Stable, Mainline, RC — what they are and which one you should use
- The different types of kernel release trees that exist
- What makes a kernel LTS (Long-Term Support) and why it matters
- The difference between mainline, stable, LTS, and EOL kernels
- How to read a kernel version number like
6.6.30 - Which kernel type to choose for your specific situation
1. Not All Kernels Are Created Equal
When you visit the official Linux kernel website kernel.org, you do not just see one kernel to download. You see several, each labelled differently — mainline, stable, longterm, EOL. This can be confusing for newcomers.
The reason is that different users have very different needs. A kernel developer experimenting with brand new features needs something very different from an engineer building a router that must stay secure for 5 years in the field. The kernel project has organised its releases to serve all these needs.
A car company sells a concept car for enthusiasts (mainline/bleeding-edge), a regular production model for everyday buyers (stable), and a fleet edition for police cars and taxis that gets serviced for 10 years (LTS). Same underlying technology — very different maintenance commitments. The Linux kernel works the same way.
2. How to Read a Kernel Version Number
Before we look at the different tree types, let us quickly decode how Linux kernel version numbers work. This removes a lot of confusion when you are browsing kernel.org or selecting a kernel for your project.
6.1Brand new stable release — no patches applied yet (also an LTS kernel)
6.1.90The 6.1 kernel with 90 rounds of bug/security patches applied by the stable team
6.10-rc3Release candidate 3 of the upcoming 6.10 kernel — not yet stable, for testing only
3. The Different Types of Kernel Trees
Here are the main kernel tree types, ordered from least stable to most stable — which also maps from shortest lifespan to longest.
This is Linus Torvalds’s own tree — the very tip of Linux development. It contains the most recent features that have been merged during the merge window, followed by a series of -rc releases as they get stabilised. Once the rc phase is complete, this tree becomes the next stable release.
Who uses it: Kernel developers and driver authors who need to develop and test against the very latest code. If you are writing a new driver that you plan to submit upstream to the kernel community, you must develop against mainline.
Expect rough edges, regressions, and changes that can break things unexpectedly.
A stable kernel is the freshly-released version after its rc phase is complete. For example, version 6.9 is a stable release. The stable team then applies important bug fixes and security patches, creating point releases like 6.9.1, 6.9.2, and so on.
Who uses it: Desktop Linux users who want recent hardware support and new features on a properly tested version. However, a regular stable kernel has a short maintenance window — it is only maintained until the next stable kernel comes out, which is roughly every 8 to 12 weeks.
An LTS kernel is a specially designated stable release that gets an extended maintenance commitment — a minimum of 2 years, often 4 to 6 years or more. Only critical bug fixes and security patches are backported into it. No new features are ever added after the initial release.
Why it matters for embedded systems: Embedded Linux products — routers, cameras, industrial controllers, medical devices — often have field lifespans of 5 to 10 years. The engineering team cannot upgrade the kernel every few months. LTS kernels give them a stable, well-maintained foundation for the entire product lifetime without the risk of breaking changes.
Who decides which kernel becomes LTS? The kernel maintainers designate certain releases as LTS based on community need and the willingness of major stakeholders — like Google for Android or major embedded Linux vendors — to commit resources to maintaining them. Roughly one kernel per year receives the LTS designation.
A kernel that has reached its EOL date is no longer maintained in any way. No security fixes, no bug fixes — nothing. If a critical vulnerability is discovered after the EOL date, users of that kernel are completely on their own. EOL kernels are archived purely for historical and research purposes.
Known vulnerabilities will remain permanently unpatched.
4. Side-by-Side Comparison
| Type | Stability | Lifespan | Best for |
|---|---|---|---|
| Mainline / RC | Low | Weeks | Kernel developers, upstream patch submission |
| Stable | Medium | ~3 months | Desktop users, testing recent features |
| LTS | High | 2–6+ years | Embedded products, production servers, Android |
| EOL | None | Expired | Historical research only — never for live systems |
5. LTS Kernels — A Closer Look
LTS kernels deserve extra attention because as an embedded or device driver engineer, this is what you will work with most of the time. Let us understand them more deeply.
What actually makes a kernel LTS?
There is nothing magical in the kernel code itself that makes it LTS. It is purely a community decision. The maintainers look at which kernel versions are being widely adopted by major stakeholders — such as Google (for Android), the Yocto Project (for embedded Linux), and major server distributions — and they commit to maintaining those versions for an extended period.
Once a kernel is designated LTS, only the following types of patches are allowed in: security fixes, critical bug fixes, and important hardware enablement patches. New features are never added to an LTS kernel after its initial release — that would defeat the entire purpose.
How long does LTS support actually last?
The minimum commitment is 2 years, but many LTS kernels get extended well beyond that. Android has historically been a major driver here — when Google pins a particular Android release to a specific LTS kernel, there is strong incentive for the entire ecosystem to keep that kernel maintained.
| Kernel | Released | EOL Date | Support Period |
|---|---|---|---|
| 5.4 LTS | Nov 2019 | Dec 2025 |
~6 years |
| 5.10 LTS | Dec 2020 | Dec 2026 |
~6 years |
| 5.15 LTS | Oct 2021 | Oct 2026 |
~5 years |
| 6.1 LTS | Dec 2022 | Dec 2026 |
~4 years |
| 6.6 LTS | Oct 2023 | Dec 2026 |
~3 years |
6. Which Kernel Should You Use?
Here is a practical decision guide based on what you are trying to do:
Use the latest active LTS kernel. Check kernel.org for current active LTS kernels. Pick the one whose EOL date is comfortably beyond your planned product end-of-life date. As of 2025, the 6.6 LTS is a solid general-purpose choice.
Use the kernel that ships with your Linux distribution (Ubuntu, Fedora, Arch). They package well-tested versions appropriate for desktop use. You do not need to compile a custom kernel for everyday development.
You must develop against mainline. Patches submitted to the kernel mailing list must apply cleanly on the latest mainline tree. Testing only on an LTS or older stable kernel will result in your patch being rejected by the maintainers.
Use an LTS kernel on your development VM. The core concepts do not change between kernel versions, but working on a stable, well-documented LTS release makes the learning process smoother and avoids distractions from chasing rapidly-moving mainline changes.
Visit kernel.org — the official Linux kernel website. The main page always lists currently active stable and LTS kernels with version numbers and their EOL dates. A yellow background indicates the latest stable release. A green background indicates a longterm (LTS) kernel.
The page kernel.org/releases.json provides the same data in machine-readable JSON format, which is useful if you are building tools that need to track kernel versions programmatically.
🎤 Interview Questions
An LTS (Long-Term Support) kernel is a specifically designated stable release that receives an extended maintenance commitment — typically 2 to 6 years or more. Only critical bug fixes and security patches are backported; no new features are added. For embedded products with long field lives, LTS kernels are essential because the product team needs a kernel that remains secure and supported throughout the product’s lifetime without requiring a complete OS upgrade.
The number breaks into three parts: major version 6, minor version 6, and patch level 42. The major version (6) rarely changes and carries no deep technical meaning. The minor version (6) identifies the specific development cycle — 6.6 is the sixth release in the 6.x series. The patch level (42) tells you that 42 rounds of bug fix or security patches have been applied to the 6.6 base by the stable team after its initial release. A higher patch level generally indicates a more mature and well-maintained version.
You must develop against the mainline (Linus’s) tree, specifically the latest -rc kernel. The kernel community requires that submitted patches apply cleanly on the current mainline tree before they will even begin review. Submitting a patch that only applies to an LTS or older stable kernel will be rejected — those trees have diverged significantly from mainline and compatibility is not guaranteed.
Both start from the same stable release process and are safe to use at launch. The difference is in their ongoing support lifespan. A regular stable kernel is maintained only until the next stable release ships — roughly 8 to 12 weeks. After that, it goes EOL. An LTS kernel continues receiving bug and security fixes for a minimum of 2 years and often much longer. LTS kernels are designated specifically because they represent solid, well-tested releases that the broader community has committed to supporting over a long time horizon.
EOL stands for End of Life — a kernel that no longer receives any maintenance, bug fixes, or security patches from the community. The primary risk is security: when new vulnerabilities are discovered (which happens continuously), they are patched in active kernels but simply left open in EOL ones. A networked system running an EOL kernel with known unpatched vulnerabilities is a straightforward attack target. There is never a valid reason to run an EOL kernel on any production or internet-connected system.
- Kernel trees are ordered: mainline → stable → LTS → EOL (increasing lifespan and stability)
- Version numbers follow major.minor.patchlevel — e.g.
6.6.42 - LTS kernels receive bug and security fixes for 2–6+ years — no new features ever
- For embedded products, always choose an active LTS kernel whose EOL outlasts your product’s lifespan
- For upstream kernel development, always target mainline
- Never run an EOL kernel on any production or networked system