How the Linux kernel release cycle works: merge window, rc weeks, stable and LTS explained
From the two-week merge window to rc1, weekly release candidates, stable updates and long-term branches: how a Linux version is made, using Linux 7.4 as the example.
· 5 min read
Written by AI from the sources linked below. How we use AI
On this page
In short
The Linux kernel ships a new version every nine to ten weeks, and every release follows the same rhythm: a two-week merge window in which new features go in, then a release candidate (-rc) every week, usually until -rc6 to -rc9, then the final release. After that a separate stable team backports fixes, and a few releases a year are designated long-term (LTS) and supported for years. The newest example is Linux 7.4-rc1, published on 1 November 2026.
Who decides what goes in
The kernel's own process documentation puts it bluntly: "There is exactly one person who can merge patches into the mainline kernel repository: Linus Torvalds." In practice he does not read every patch. Work flows through subsystem maintainers (networking, graphics drivers, file systems and so on), who collect patches from contributors, review them, and send Torvalds pull requests. The documentation's example is Linux 2.6.38: of more than 9,500 patches, Torvalds chose only 112 directly; the rest came through maintainers.
Before a change reaches Torvalds it is expected to have spent time in linux-next, a tree maintained by Mark Brown that is a snapshot of what mainline should look like after the next merge window closes. It exists to catch conflicts between subsystems early.
The cycle, step by step
- The merge window (about two weeks). Right after a release, maintainers send Torvalds the changes they have prepared. The documentation says the window lasts "approximately two weeks" and that most of a release's major changes land here.
- rc1. At the end of the window Torvalds tags the first release candidate. It signals that "the time to merge new features has passed", and from then on only fixes are supposed to be accepted.
- Weekly release candidates. A new -rc follows roughly every week. The documentation says a normal series reaches "somewhere between -rc6 and -rc9" before the final release, and that stabilisation usually takes six to ten weeks.
- The final release. When Torvalds judges the tree stable, he tags the release. The whole cycle takes two or three months; kernel.org says new mainline kernels arrive about every nine to ten weeks.
- The next merge window opens at once. Maintainers start sending the next batch while the previous release moves to the stable team.
Linux 7.4 is a live example. According to Linux Compatible, 7.3 shipped on 18 October 2026 and the merge window opened right away; kernel.org lists 7.4-rc1 dated 2026-11-01, exactly two weeks later. Our report on that release covers the record number of commits it contained.
After release: stable and long-term kernels
Once a release ships, it is handed to the stable team, which the documentation says currently consists of Greg Kroah-Hartman and Sasha Levin. They publish updates numbered with a third digit, such as 7.3.1, which you can see on kernel.org (it lists stable 7.3.1 dated 2026-10-30).
Not every bug fix qualifies. The documentation says a patch must fix a significant bug and already be merged into the mainline for the next development kernel. Stable kernels normally receive updates for a little more than one development cycle after release, which is why kernel.org shows an old branch such as 7.2.15 marked "[EOL]".
Some kernels are designated long-term. They are maintained for years to backport important fixes to older trees. Kernel.org lists these longterm branches and their projected end of life:
| Version | Released | Projected end of life |
|---|---|---|
| 6.18 | 2025-11-30 | December 2028 |
| 6.12 | 2024-11-17 | December 2028 |
| 6.6 | 2023-10-29 | December 2027 |
| 6.1 | 2022-12-11 | December 2027 |
| 5.15 | 2021-10-31 | December 2026 |
| 5.10 | 2020-12-13 | December 2026 |
Kernel.org notes these dates are "not set in stone" and can be extended if enough industry interest exists.
How a long-term kernel gets chosen
There is no formal schedule. The process documentation says a kernel becomes long-term depending on whether a maintainer has the need and the time, and it states there are no known plans for any specific upcoming release. That is why the claim that 7.4 will be the next LTS should be treated as expectation. In Torvalds' rc1 mail, as quoted by The Register, he said only that "people are expecting 7.4 to be the next LTS". Kernel.org's list of longterm kernels does not include 7.4.
What this means for you
- If you run a distribution kernel, you are usually on a stable or longterm branch chosen by your distribution, not on mainline. The branch's end-of-life date, not the version number, tells you how long fixes will keep arriving.
- If you are testing, rc releases are the time to report regressions; a bug found in -rc3 is far easier to fix than one found after release.
- If you maintain a product on Linux, pick a longterm branch and check its projected end of life against your support promise. Note that 5.15 and 5.10 are both projected to end in December 2026.
- If you contribute, send changes through the subsystem maintainer and aim for them to be in linux-next before the merge window; a patch that arrives during the -rc weeks must be a fix.
Why the rhythm matters now
The rhythm has been under pressure from the volume of fixes found by AI tools. The Register reports Torvalds saying he is "much happier with the flood of AI triggered work going into the merge window than it showing up mainly as extra fixes during the -rc period", because the cycle is designed to take new work early and only fixes late. Hardware Busters puts the 7.4 merge window at 19,671 commits against 12,468 for 7.0, a sign of how much more is flowing through the same two-week window. Whether the schedule holds, with nine to ten weeks per release, is something the next few release candidates will show.
What we don't know
Neither the date of the Linux 7.4 final release nor whether it will be a long-term kernel has been announced. Linux Compatible expects a late-December release, possibly slipping to mid-January 2027; that is a projection.
Sources
- Linux kernel documentation: How the development process works
- kernel.org front page
- kernel.org: releases (mainline, stable, longterm)
- The Register: Linus Torvalds says Linux kernel is out of 'stabilization phase'
- Hardware Busters: Linux 7.4 merge window record
- Linux Compatible: Linux Kernel 7.4 is shaping up fast
Written by
The official account of the people who run audiotale.net: announcements, conversation starters and the newsroom's drafts. Posts written with AI say so. Every other account here is a real person.
Read next
Linux 7.3 released: failfs, fchroot(), programmable binfmt_misc and a record 18,765 commits
Linus Torvalds shipped Linux 7.3 on 18 October with a new sandboxing primitive, finished per-cgroup BPF schedulers and faster Btrfs and ext4.
audiotale.net team7 min read
Linux 7.4-rc1: record 19,671-commit merge window, Torvalds on AI fixes
Torvalds says AI-found fixes now arriving in the merge window, not late in the rc weeks, are a 'much healthier model'; the tree grew by about 455,000 lines of code.
audiotale.net team6 min read
Six unpatched Linux kernel flaws, two rated CVSS 9.0 in SMB code, posted to public LKML by ZDI
Trend Micro's Zero Day Initiative reports for SMB Direct, ksmbd, vmwgfx, nvmet and more reached the public mailing list without patches; here is how to limit exposure.
audiotale.net team7 min read