Linux kernel release cadence explained in 5 points

Linux kernel updates usually arrive as short bugfix runs, with stable fixes about once a week.

Linux kernel releases are easy to misunderstand if you only see version numbers. This guide breaks the update cycle into 5 clear points, including the usual weekly stable cadence and the role of longterm maintenance kernels.

1. Mainline releases set the pace

The Linux kernel follows a mainline release track where new versions land first, then get bugfix updates as needed. That means the version you see is often just the starting point for a short correction cycle, not the final word on stability.

For readers tracking updates, the key idea is that a mainline release is the base for later fixes. It is the version that downstream users, distros, and maintainers watch before deciding what to ship or backport.

• Mainline version appears first
• Bugfixes follow after release
• Later updates may be small and targeted

2. Most bugfix runs are short

There are usually only a few bugfix kernel releases before the next mainline kernel arrives. In practice, that keeps the update window compact and makes each release cycle feel more like a short cleanup phase than a long patch stream.

This matters because it explains why some kernel versions move on quickly. If you are waiting for a specific fix, you often only have a limited number of point releases before attention shifts to the next mainline version.

• Few bugfix releases per cycle
• Next mainline version usually follows soon after
• Point releases often focus on corrections, not new features

3. Longterm maintenance kernels stay active longer

Not every kernel follows the same short cycle. When a kernel is designated a longterm maintenance kernel, it gets extended support and ongoing fixes beyond the usual mainline window. That gives organizations a slower-moving target for deployment and support planning.

Longterm kernels are useful when you want predictability over novelty. They reduce the pressure to chase every new mainline release, especially in environments where compatibility and maintenance windows matter more than rapid feature turnover.

• Extended support period
• More predictable update planning
• Common choice for conservative deployments

4. Stable updates arrive as needed

Stable kernel updates are released on an as-needed basis, usually once a week. That schedule is not a fixed promise of weekly changes, but it does set expectations for how often maintainers typically bundle fixes into a stable release.

For users and admins, this means stable branches are active but measured. You can expect regular maintenance without assuming every week will bring a release, and you can plan around that rhythm when tracking security or reliability fixes.

Typical stable cadence: about 1 release per week, as needed

5. Version numbers do not tell the whole story

A kernel version number can hide a lot of context. Two releases may look close on paper, yet belong to different support tracks, different maintenance goals, or different release rhythms. The important question is not only what number you are on, but which branch that number belongs to.

That is why kernel users should check whether a release is mainline, stable, or longterm. Those labels tell you more about update frequency and support duration than the number alone.

• Mainline: newest release path
• Stable: regular bugfix updates
• Longterm: extended maintenance focus

How to decide

If you want the newest code, follow mainline releases. If you need regular fixes with a predictable cadence, stable updates are the better fit. If your priority is long support and fewer changes over time, a longterm maintenance kernel is usually the safer choice.

In short, the best kernel track depends on whether you care most about freshness, steady maintenance, or long-term stability. The release number matters, but the support label matters more.