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 will 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 covering networking, filesystems, drivers, security, and more.
For roughly 2 weeks, new features, new drivers, and new subsystem improvements all get merged into the mainline tree — that is Linus’s own tree. The actual coding work happened months before this. Developers were writing and testing their patches for a long time. The merge window is simply when the approved work officially lands in the mainline tree.
After 2 weeks, the merge window shuts. From this point on, absolutely no new features go in. If your feature did not 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 on adding more code.
The first release candidate, 5.x+1-rc1, is tagged and published. These are also called prepatch kernels. The only job now is to find and fix bugs. Each week (roughly), a new rc version comes out — rc2, rc3 and so on. This phase typically runs for 6 to 10 weeks. When Linus Torvalds and Andrew Morton (the key maintainers) are satisfied that the kernel is solid, they call the rc phase done.
If you want to test brand-new kernel changes before they are officially released, you can run these rc kernels on your development machine. They are strictly for testing — never for production use.
Version 5.x+1 is officially released. Linux distributions start packaging it, hardware manufacturers begin testing compatibility, and the community moves on. 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. You will then see versions like 5.x+1.1, 5.x+1.2, and so on. This continues until the next stable release or until the kernel reaches its End of Life (EOL) date.
3. A Real Example — How the 5.4 Kernel Was Born
Let us make this concrete. The Linux 5.4 kernel — an important LTS release — went through this exact process. Here is 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 how the merge window opened the moment v5.3 shipped, closed after 2 weeks, then 8 weeks of rc kernels ran until the stable v5.4 came out. By early December 2019, v5.5-rc1 was already out — showing that the process truly never stops.
4. Who Controls All This?
The kernel development process has a clear hierarchy. Here is a simplified view of how code flows from an individual developer all the way to the mainline tree:
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 both are 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 project. Your product might ship 2–3 years later, and you want a kernel that will still receive security backports for the entire product lifetime. Never build a commercial product on a mainline or rc kernel.
5. The Complete Cycle at a Glance
Here is 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 point!)
Week 3 : v5.x+1-rc1 released -> RC phase begins
Week 4 : v5.x+1-rc2 (bug fixes, regression testing)
…
Week 10-12: v5.x+1-rcN (last rc, all known bugs fixed)
Week 12 : v5.x+1 STABLE releasedAfter 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 merge window is a roughly 2-week period that opens immediately after a stable kernel release. During this time, new features, drivers, and subsystem improvements are accepted and merged into Linus Torvalds’s mainline kernel tree. Once the merge window closes, no new features are accepted until the next cycle — only bug fixes are allowed from that point on.
A release candidate (also called a prepatch or -rc kernel) is a pre-release version of the upcoming stable kernel. After the merge window closes, rc1 is the first version to enter the stabilisation phase. Each subsequent rc (rc2, rc3 …) contains only bug fixes. RC kernels are not suitable for production — they are intended for developer testing and community feedback only.
A full kernel release cycle takes approximately 10 to 12 weeks. This includes about 2 weeks for the merge window and 6 to 10 weeks for the rc (release candidate) phase. As a real-world example, the v5.4 kernel took 70 days — from the moment the merge window opened (when v5.3 shipped) to the day v5.4 was tagged as stable.
After a stable kernel is released, a dedicated “stable team” takes over maintenance. They backport critical bug fixes and security patches, producing point releases such as 5.x.1, 5.x.2, and so on. Regular stable kernels are maintained until the next stable release ships. LTS kernels receive this treatment for much longer — sometimes 4 to 6 years.
Linus Torvalds and Andrew Morton are the primary decision-makers. They review the number and severity of open bug reports across all the rc releases. When they determine that remaining issues are minor and the kernel is stable enough for general use, Linus tags the final release and announces it on the Linux Kernel Mailing List (LKML).
- 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