Linux 7.1.8 Is Stable While 7.2 Is Still a Release Candidate

Kernel.org’s release table can look like a version leaderboard. It is not. On 13 August 2026, the upstream page listed 7.2-rc7 as mainline and 7.1.8 as stable; its newest published timestamps for both were 9 August 1. The longterm rows continued on older series, including 6.18, 6.12, 6.6, 6.1, 5.15, and 5.10.

The practical news is not “everyone should install 7.1.8.” It is that upstream development and stabilization are in different lanes, while distributions add a third lane with their own configuration, patches, signing, and support.

The snapshot, with its date attached

This table is a dated observation, not a promise. Stable updates can arrive quickly, a new mainline release changes the lane names, and maintainers can revise projected end-of-life dates. Check the live release and active-kernel pages before making an operational decision 1 2.

uname -sr
cat /proc/version

Those commands answer a different question: what this machine booted. They do not say which package owns the kernel, whether it is supported, or what other bootable kernels remain installed.

Mainline does not mean production default

The mainline tree is where Linus Torvalds integrates work for the next release. After the merge window, release candidates are published while testing and fixes continue. The kernel development-process documentation describes this cycle and notes that the -rc series is for stabilization 3.

That makes 7.2-rc7 useful for:

• checking whether a suspected upstream regression is already fixed;
• validating new hardware before the final 7.2 release;
• testing an out-of-tree module against the next interface;
• producing a high-quality report for upstream maintainers.

It does not make 7.2-rc7 a routine replacement for a distribution kernel on a machine whose availability matters. An RC deliberately sits before the final release.

Stable does not mean “supported by my distribution”

The stable team publishes focused fixes after a mainline release. Linux 7.1.8 is therefore newer upstream than 7.1, but an Ubuntu, Debian, Fedora, SUSE, or other distribution kernel can carry an older-looking version with backported fixes and a distribution-specific build suffix.

Inspect the package relationship before comparing only uname strings:

# Debian and Ubuntu family
dpkg-query -S "/boot/vmlinuz-$(uname -r)" 2>/dev/null
apt-cache policy "linux-image-$(uname -r)" 2>/dev/null

# Fedora family
rpm -qf "/boot/vmlinuz-$(uname -r)" 2>/dev/null
dnf info "kernel-core-$(uname -r)" 2>/dev/null

Run the pair that fits the host. A kernel delivered by the normal package channel inherits that distribution’s update, Secure Boot, initramfs, and support workflows. A kernel copied into /boot by hand does not automatically inherit any of them.

A safe upgrade decision

Use evidence in this order:

1. Identify the running kernel and the package that supplied it.
2. Read the distribution advisory or package changelog for the update offered.
3. Confirm that an older known-good kernel remains bootable.
4. Check external modules, disk encryption, filesystems, and Secure Boot.
5. Reboot in a maintenance window, then verify the running version and service health.

For a regression, preserve both the last known-good and first known-bad kernel versions. The upstream reporting guide asks reporters to describe the failure, environment, and regression range and to involve the relevant maintainers 4. “It broke on Linux 7” is much less actionable than two exact package versions and a reproducible symptom.

What this update does not establish

This article does not benchmark 7.1.8, certify a particular hardware device, or recommend a mainline build over a vendor kernel. It also does not infer that a longterm series is supported for the same duration by every distribution.

The useful reading of the August snapshot is simple: 7.1.8 is the current upstream stable update, 7.2-rc7 remains pre-release, and your distribution’s supported package is the default operational boundary.