For more than three decades, the Linux kernel has served as the invisible backbone of modern computing — powering everything from Android smartphones and cloud data centers to the International Space Station. Now, as the project approaches a symbolic milestone, its creator Linus Torvalds has signaled that the next major release could carry a version number that breaks sharply from recent convention: Linux 7.0. The move, while largely cosmetic in technical terms, arrives at a moment when the kernel is undergoing one of its most consequential internal transformations — the steady integration of the Rust programming language alongside its venerable C codebase.
According to reporting by Phoronix, Torvalds has indicated that the jump from the current Linux 6.x series to version 7.0 is on the horizon, continuing his established pattern of incrementing the major version number when the minor version count grows unwieldy. Torvalds has historically bumped the major number not because of a revolutionary technical change, but simply because he finds large minor version numbers aesthetically displeasing. The leap from 5.x to 6.0 occurred in October 2022 when the minor versions had reached 5.19. A similar threshold is now approaching for the 6.x series, and Torvalds has suggested that Linux 7.0 could arrive once the numbering feels excessive — potentially around 6.16 or later in 2025.
A Numbering Philosophy Rooted in Pragmatism, Not Revolution
Torvalds has been remarkably consistent in downplaying the significance of major version bumps. When Linux moved from 3.x to 4.0 in 2015, and again from 4.x to 5.0 in 2019, he emphasized that the changes were about keeping version numbers manageable rather than marking a dramatic shift in the kernel’s architecture. “I don’t want to let the minor numbers get too big,” Torvalds has said in past kernel mailing list discussions, a sentiment he has reiterated as the 6.x series matures. The community largely understands and accepts this convention, though it occasionally sparks debate among those who believe major version numbers should correspond to major technical milestones.
That said, the timing of a potential Linux 7.0 release is noteworthy because the kernel is in the midst of a genuinely significant evolution. The integration of Rust — a memory-safe systems programming language developed originally at Mozilla — represents the most important new language addition to the Linux kernel since its inception in 1991. While Torvalds may not choose to align the version bump with Rust’s progress, the convergence of these two storylines gives the 7.0 milestone more narrative weight than its predecessors enjoyed.
Rust’s Expanding Footprint Inside the Kernel
Rust support was first merged into the Linux kernel with version 6.1 in December 2022, initially as experimental infrastructure that allowed developers to write kernel modules in Rust. Since then, each successive release has expanded Rust’s presence. Early efforts focused on building the foundational abstractions — safe wrappers around core kernel APIs — that would allow Rust code to interact with the existing C infrastructure without introducing undefined behavior or memory safety violations. As Phoronix has documented, recent kernel releases have seen Rust code move beyond proof-of-concept territory into subsystems that handle real workloads.
The Rust-for-Linux project, led by developer Miguel Ojeda and supported by contributors from Google, Microsoft, Samsung, and other major technology firms, has methodically built out driver support, filesystem abstractions, and networking primitives. Google has been particularly aggressive in championing Rust within Android’s kernel stack, citing internal data showing that memory safety bugs account for a disproportionate share of critical vulnerabilities. By introducing Rust, the kernel community aims to reduce the class of bugs — buffer overflows, use-after-free errors, data races — that have plagued C codebases for decades.
Industry Heavyweights Bet on Memory Safety
The push toward memory-safe languages in systems programming has gained powerful institutional backing. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the White House Office of the National Cyber Director have both published guidance urging software developers to adopt memory-safe languages wherever feasible. These recommendations, while not mandates, have added political and regulatory momentum to efforts like Rust-for-Linux. For enterprise Linux distributors such as Red Hat, SUSE, and Canonical, the prospect of a kernel with fewer memory safety vulnerabilities translates directly into reduced patching burdens and improved security postures for their customers.
Microsoft, which operates one of the world’s largest Linux deployments through Azure, has invested heavily in Rust across its software stack and has contributed engineering resources to Rust kernel development. Google’s Android team has reported measurable declines in memory safety vulnerabilities as Rust adoption has increased in Android’s lower-level components. These real-world results lend empirical support to the theoretical benefits of Rust and have helped overcome skepticism among veteran kernel developers who are deeply invested in C.
Tensions and Growing Pains in the Kernel Community
The introduction of Rust has not been without friction. Some longtime kernel maintainers have expressed concern about the added complexity of supporting two languages, the learning curve associated with Rust’s ownership and borrowing model, and the potential for a cultural divide between C and Rust developers. In 2024, several high-profile mailing list discussions revealed tensions around the pace of Rust integration, with some subsystem maintainers pushing back against Rust patches in their domains. Torvalds himself has taken a measured approach, generally supporting Rust’s inclusion while acknowledging that the transition will take years and must respect the existing development culture.
The governance challenge is real. The Linux kernel’s development model relies on a distributed hierarchy of maintainers, each responsible for specific subsystems. Introducing Rust means that maintainers must either learn the language themselves or accept contributions they cannot fully review — a proposition that runs counter to the kernel’s rigorous code review culture. The Rust-for-Linux team has worked to mitigate this by providing extensive documentation, mentorship, and by focusing initial efforts on new drivers and modules rather than rewriting existing C code.
What Linux 7.0 Could Look Like
If current development cadences hold, Linux 7.0 could arrive in late 2025 or early 2026. By that point, the kernel is expected to contain significantly more Rust code than it does today, potentially including production-ready drivers for hardware used in data centers and mobile devices. The Apple M-series GPU driver, written in Rust by Asahi Linux developer Asahi Lina, has become one of the most prominent examples of Rust’s viability for complex, performance-sensitive kernel work. Its continued maturation could serve as a powerful proof point by the time 7.0 ships.
Beyond Rust, the 7.0 kernel will likely incorporate advances in scheduler design — including continued refinement of the EEVDF (Earliest Eligible Virtual Deadline First) scheduler that replaced the longstanding CFS in Linux 6.6 — as well as improvements to io_uring, the high-performance asynchronous I/O framework that has become critical for modern database and networking workloads. Support for emerging hardware architectures, including RISC-V, is also expected to deepen, further broadening the kernel’s reach across the computing spectrum.
The Symbolic Weight of a Version Number
For industry insiders, the move to Linux 7.0 is less about the number itself and more about what the kernel contains when it arrives. The version bump will be, as Torvalds has always insisted, a housekeeping decision. But the kernel that carries that number will be materially different from the one that launched the 6.x series. It will be a kernel in which Rust is no longer experimental but operational, in which memory safety is an engineering priority endorsed by governments and corporations alike, and in which the community has navigated — however imperfectly — one of the most significant technical transitions in its history.
The Linux kernel has always evolved incrementally, absorbing new technologies and adapting to new demands without the dramatic ruptures that characterize some commercial software projects. Linux 7.0 will be no exception in form. But in substance, it may represent the moment when the kernel’s future as a multilingual, memory-safe operating system foundation becomes irreversible. For the companies, developers, and institutions that depend on Linux — which is to say, virtually all of them — that is a development worth watching closely.
WebProNews is an iEntry Publication