Linus Torvalds is once again entertaining the idea of bumping the Linux kernel’s major version number, this time from 6.x to 7.0. Not because of some sweeping architectural overhaul. Not because the kernel is fundamentally changing. Simply because the minor version numbers are getting unwieldy — and Torvalds has done this before.
The discussion surfaced during the Linux 6.16 merge window, with Torvalds signaling that the jump could happen as soon as the release after 6.16, which would make what might have been Linux 6.17 into Linux 7.0 instead. As reported by Phoronix, this versioning shift carries no technical weight — it’s purely cosmetic. But it matters to the broader community for reasons both practical and psychological.
Torvalds made the same move in 2015 when he jumped from Linux 3.19 to 4.0, and again in 2022 when 5.19 became 6.0. His reasoning has been consistent: once the minor number climbs past the teens, it becomes annoying. “I’ll likely bump things up and call it 7.0 just because I’m starting to worry about running out of fingers and toes,” Torvalds wrote on the Linux kernel mailing list during the 6.15 cycle, according to Phoronix’s earlier reporting. The threshold this time appears lower — 6.16 or 6.17 rather than waiting for 6.19 — suggesting Torvalds may simply be less patient with high minor numbers than he used to be.
For enterprise users, distro maintainers, and anyone writing version-detection scripts, the change is trivial but requires attention. Software that parses kernel version strings with assumptions about single-digit major numbers broke during the 2.x-to-3.0 transition years ago. Most tooling has long since been fixed. Still, a major version bump always flushes out a few dusty corners of version-checking code that nobody remembered existed.
The PostgreSQL AWS Driver Removal: A Quiet but Telling Change
Buried in the same 6.16 merge window is a far more consequential development for cloud database infrastructure. The kernel is dropping the Amazon Web Services (AWS) PostgreSQL driver — specifically, the “aws” driver code that had been merged into the PostgreSQL-related kernel infrastructure.
This isn’t about PostgreSQL itself disappearing from Linux. The removal targets a specific kernel-level driver associated with AWS’s cloud database connectivity layer. According to Phoronix, the driver is being removed because it has gone unmaintained. No active developer has stepped up to keep it current, and the kernel community has a well-established policy: code without a maintainer eventually gets cut.
The Linux kernel’s stance on unmaintained drivers is unambiguous. If nobody is willing to fix bugs, handle security patches, and keep the code aligned with evolving kernel APIs, it gets removed. This is how the kernel stays functional at scale — roughly 30 million lines of code can’t carry dead weight indefinitely. The AWS PostgreSQL driver’s removal follows this pattern precisely.
What makes this particular removal interesting is the AWS angle. Amazon is one of the largest contributors to the Linux kernel and one of its biggest commercial consumers. AWS runs Linux on millions of servers. The company employs kernel developers and has historically been proactive about maintaining its upstream contributions. So when an AWS-associated driver falls into disrepair and gets axed, it raises questions. Did AWS shift its approach to this particular functionality? Did the driver become redundant because of changes in how AWS handles PostgreSQL workloads internally? Or did it simply fall through the cracks in a large organization’s open-source priorities?
Amazon hasn’t publicly commented on the removal. But the pattern is familiar across the industry — companies contribute drivers or modules to the kernel during a specific product phase, then quietly deprioritize them as internal architectures evolve. The kernel community doesn’t wait around for corporate roadmap clarity. Unmaintained means removed.
For AWS customers running PostgreSQL workloads, the practical impact appears minimal. AWS’s managed database services like RDS and Aurora PostgreSQL operate through userspace tooling and proprietary infrastructure layers, not through a single kernel driver. The removal likely reflects a shift away from a kernel-level approach that AWS no longer considers necessary rather than any degradation of PostgreSQL support on the platform.
What’s Actually Coming in Linux 6.16
Beyond the versioning talk and the driver removal, the 6.16 merge window has brought a substantial batch of changes. The kernel continues its steady cadence of hardware enablement, performance tuning, and security hardening.
Among the notable additions: continued work on Rust language support within the kernel, further improvements to the io_uring subsystem for high-performance I/O, and ongoing refinements to power management across ARM and x86 platforms. The Intel and AMD GPU driver updates are, as usual, among the largest patch sets in any given merge window. Filesystem work continues on Btrfs and XFS, with incremental but meaningful improvements to reliability and performance.
The Rust integration story deserves particular attention. What started as an experimental effort has gained real momentum, with more subsystems accepting Rust-written components alongside traditional C code. This isn’t a rewrite — it’s a gradual expansion of the surface area where memory-safe code can operate within the kernel. Torvalds has been broadly supportive, though the pace remains deliberate. Each merge window brings a few more pieces of the Rust infrastructure into place.
And then there’s the security front. Kernel hardening patches continue to flow in, addressing speculative execution vulnerabilities, improving memory isolation, and tightening access controls. These aren’t headline-grabbing features, but they’re the kind of steady, unglamorous work that keeps Linux viable as the foundation for everything from smartphones to supercomputers to cloud hypervisors.
The 6.16 release is expected to stabilize over the coming weeks, with a final release likely in late July or early August 2025, following the kernel’s typical roughly-nine-week release cycle. If Torvalds follows through on the version bump, the subsequent release would be Linux 7.0 — probably arriving in the fall.
So what does a version 7.0 kernel actually mean? In functional terms, nothing. In symbolic terms, it marks another chapter in the kernel’s now 34-year history. Every major version bump generates a brief flurry of attention from the tech press and mild confusion among users who assume a major number change implies a major capability change. It doesn’t. Torvalds has been explicit about this for over a decade.
But the numbering does serve as a useful timestamp. The 4.x era roughly corresponded to the mid-2010s push into containers and cloud-native workloads. The 5.x series saw the rise of ARM server support and early Rust experiments. The 6.x cycle has been defined by the maturation of those efforts plus intensive work on hardware support for next-generation CPUs and GPUs. Whatever 7.x brings, it will be shaped by the same forces: hardware vendors demanding driver support, cloud providers needing performance and security, and a developer community that remains, against all odds, remarkably productive.
The PostgreSQL driver removal and the version number discussion, taken together, illustrate something fundamental about how Linux development works. The kernel is simultaneously conservative — removing code that isn’t maintained, following strict processes for merging new features — and willing to make pragmatic, even whimsical decisions about things like version numbering. It’s a project governed by engineering discipline and one person’s aesthetic preferences about how high a number should count before rolling over.
That combination has worked for three decades. There’s no reason to think it won’t keep working for the next one.
WebProNews is an iEntry Publication