›
Chapter 2 – Part 1: Kernel Source Basics
›
Part 2: Kernel Development Cycle
›
Part 3: Types of Kernel Trees →
How a Linux Kernel Release is Born
Understanding the development cycle — from merge window to stable release
- Why Linux kernel releases follow a strict time-based schedule
- What the merge window is and why it matters
- What release candidates (rc) are and what happens during that phase
- The full 6-step cycle from one stable release to the next
- What LTS (Long-Term Support) means in the kernel world
1. Why Does the Kernel Have a Development Cycle?
The Linux kernel is one of the most actively developed software projects in the world. Thousands of engineers — from big companies like Intel, Google, Samsung, and Red Hat — contribute code to it every single day. Without a structured process, things would fall apart fast.
So the kernel community follows a time-based release model. Instead of saying “we will release when features are ready,” they say “new features go in during a fixed window, then we stabilise and ship on schedule.” This predictability is why Linux powers everything from your Android phone to the world’s fastest supercomputers.
A city train runs every 10 weeks. You can board with your luggage (new code) during the first 2 weeks. After that, the doors close — no new passengers. The remaining 8 weeks are spent making sure the journey is smooth and all problems are fixed before arrival. Miss this train? You wait for the next one. This is exactly how each Linux kernel release works.
2. The 6-Step Kernel Release Cycle
Let’s walk through each step. We’ll use the 5.x kernel series as our example — the same pattern applies to 6.x, 7.x, or any future series.
When version 5.x is released, the merge window for 5.x+1 automatically opens. The release of one kernel is the starting gun for the next one. Linus Torvalds and his lieutenants now accept pull requests from subsystem maintainers (networking, filesystems, drivers, etc.).
For roughly 2 weeks, new features, new drivers, new subsystem improvements — all get merged into the mainline tree (Linus’s tree). Understand: the actual coding work happened months before. Developers were writing and testing their patches for a long time. The merge window is just when the approved work lands in the official tree.
After 2 weeks, the merge window shuts. From this point on, absolutely no new features go in. If your feature didn’t make it in time, you wait for the next cycle. This strict rule is what keeps the kernel manageable — it forces focus on quality, not quantity.
The first release candidate, 5.x+1-rc1, is tagged and published. These are also called prepatch kernels. The only job now: find and fix bugs. Each week (roughly), a new rc version comes out — rc2, rc3 … rcN. This phase typically runs for 6 to 10 weeks. The number of rc releases varies depending on how many bugs show up. When Linus and Andrew Morton (the key maintainers) are satisfied that the kernel is stable, they call it done.
If you want to test brand-new kernel changes before they are officially released, you can use these rc kernels on your development machine. They are not for production use.
Version 5.x+1 is officially released. The community celebrates, distros start packaging it, device manufacturers begin testing it. And immediately, the merge window for 5.x+2 opens — the cycle continues without pause.
After the major release, a dedicated stable team takes over. Their job is to backport critical bug fixes and security patches into the released version. So you will start seeing versions like 5.x+1.1, 5.x+1.2, and so on. This continues until the next stable release or the kernel reaches its End of Life (EOL) date.
3. A Real Example — How the 5.4 Kernel Was Born
Let’s make this concrete. The kernel 5.4 — which is an important LTS release — went through this exact process. Here’s how the timeline looked:
| Date | Event | Phase |
|---|---|---|
| 15 Sep 2019 | v5.3 stable released | Merge Window Opens |
| 30 Sep 2019 | v5.4-rc1 tagged | RC Phase Starts |
| 06 Oct 2019 | v5.4-rc2 | Bug Fixing |
| 13–27 Oct 2019 | v5.4-rc3 → rc5 | Bug Fixing |
| 03–17 Nov 2019 | v5.4-rc6 → rc8 (last rc!) | Final Stabilization |
| 24 Nov 2019 | v5.4 stable released 🎉 | Stable Release |
Notice the pattern: the merge window opened when v5.3 shipped, closed after 2 weeks, then the rc kernels ran for about 8 weeks (in this case), and finally the stable v5.4 came out. And by early December 2019, v5.5-rc1 was already out — showing that the process never stops.
4. Who Controls All This?
The kernel development process has a clear hierarchy. Here’s a simplified view of how code flows from a developer to the mainline:
Mainline (torvalds/linux)
Maintainer
Maintainer
Maintainer
Maintainer
The two most important names in kernel releases are Linus Torvalds (creator of Linux, manages the mainline tree) and Andrew Morton (one of his most trusted lieutenants). When they are both satisfied that the rc phase is done, the stable version is tagged and announced on the Linux Kernel Mailing List (LKML).
If you are writing a Linux kernel driver for an embedded product, always target the latest LTS kernel available at the time you start. Your product might ship 2–3 years later, and you want a kernel that will still receive security backports. Never build a product on a mainline or rc kernel.
5. The Complete Cycle at a Glance
Here’s the entire cycle condensed into one clean view:
====================Week 0 : v5.x released → Merge window for v5.x+1 OPENS
Week 1-2 : New features from subsystem trees merge into mainline
Week 2 : Merge window CLOSES (no new features after this!)
Week 3 : v5.x+1-rc1 released → RC phase begins
Week 4 : v5.x+1-rc2 (bug fixes, regressions)
…
Week 10-12: v5.x+1-rcN (last rc, all known bugs fixed)
Week 12 : v5.x+1 STABLE released 🎉After release:
→ Stable team takes over
→ v5.x+1.1, .2, .3 … released with critical backports
→ Meanwhile, merge window for v5.x+2 is already open!
🎤 Interview Questions
- The kernel follows a time-based release model — roughly every 10–12 weeks
- The merge window (2 weeks) is the only time new features are accepted
- The rc phase (6–10 weeks) is for bug fixing and stabilisation only
- After release, the stable team maintains it with patch releases (x.y.1, x.y.2 …)
- As an embedded developer, always target an LTS kernel for product development