The first release candidate for Mir 2.31.0 has been tagged, freezing the public API across all nine shared libraries. Between the 2.30.0 release and this RC, roughly 359 commits landed from nearly 20 contributors, including a new ext_foreign_buffer_v1 Wayland protocol for privacy-preserving screen capture. The release also wires up output configuration, supports libinput 1.32 circular scrolling, and continues hardening Mir's mandatory Rust build. It's a stabilization cycle rather than a disruptive one, so expect the final 2.31.0 to ship once testing confirms the API is solid.

Canonical tags Mir 2.31.0 release candidate, freezes the API ahead of final release

The first release candidate for Mir 2.31.0 landed Saturday at 23:02 UTC, and the API is now frozen.

On Saturday at 23:02:58, Canonical's automated CI bot tagged v2.31.0-rc with a commit message that gets right to the point: "Begin Release Candidate for 2.31.0 release." An RC is the project's way of declaring the feature set complete and handing the testing over to the community. Anything found broken can still be fixed now. If nothing blocks it, 2.31.0 gets its final stamp.

The detail worth locking in for anyone integrating against Mir: all nine of its shared libraries are keeping the exact same ABI versions they had in 2.30.0. That means no new interface churn is expected heading into the final. ABI levels only get bumped when a public interface actually changes, so "nothing moved" is exactly the signal you want to see.

Keep in mind the usual caveats at this stage. Canonical's dedicated 2.31 release-notes page is still marked "Unreleased," with empty feature sections, and the docs carry a mirserver ABI digit that conflicts with 2.30.0's bump to 69. That's normal for an RC, since the polished changelog usually gets written around or after the final release. The verifiable claim here is simply that no library ABI was bumped between the 2.30 baseline and this RC.

What actually changed in the code

Between 2.30.0 and this RC landed roughly 359 commits across about 396 files, with close to 20 contributors lending a hand. It's been a real work window rather than a quiet minor bump.

The standout is ext_foreign_buffer_v1, a new Wayland protocol. It belongs to a family of "foreign buffer" protocols that let one client capture or embed another client's rendered content. Per Canonical's office-hours notes, the use case is "live image captures like alt-tab switchers without exposing content." App switchers and screen-capture tools can preview other windows without leaking their full contents to unprivileged observers. Canonical intends to submit the protocol upstream to the Freedesktop wayland-protocols repo, matching a specific roadmap item.

Then there's a graphics refactor. RAOF split the RenderingProviders and DisplayProviders out of platform.h, a structural cleanup that makes the platform API a bit easier to consume. A separate commit added a BlitterRenderingProvider interface for blit-only rendering paths. The longer-term goal is letting custom renderer modules ship as standalone GPU-support snaps.

Output configuration got wired up too. One commit calls DisplayConfigurationPolicy::confirm() after you change a display layout, part of building out Mir's public output-configuration mechanism. That directly answers a gap the team flagged back in September: the Wayland ecosystem currently has no standardized display configuration protocol, so Mir is filling in the blank.

The build side stayed busy as well. Rust remains a mandatory dependency, 2.30 made it required, and 2.31 continues hardening that path. Native builds for Debian landed, a fork-bomb fix stopped cargo from spawning out of control, and source-package uploads now actually build with rustc present.

What Mir actually is

If you haven't dug into Mir, it's a set of open-source C++ libraries for building graphical shells on Linux. It isn't a desktop itself, so think of it as a toolkit that shell authors link against. Mir bundles what used to need a separate window manager, compositor, and display server into one modular library. It implements Wayland, so Wayland apps run natively, and it ships Xwayland as a per-client sandbox for the occasional X11-only app.

Canonical's angle has always been security. Since every app talks to the Mir server only through its own socket, a malicious client can't freely snoop on other apps' keystrokes or screen contents. That's what makes Mir attractive for kiosks, point-of-sale terminals, signage, and in-car displays, the kind of hardware that's often unattended.

The history explains the current posture. Canonical announced Mir in 2013 as part of Unity 8, the phone and desktop shell. It shipped with the Ubuntu tablet effort. Unity 8 got dropped as a consumer desktop around 2017 in favor of GNOME, but Mir was kept around and repurposed for IoT, embedded, and edge devices. It found a durable second life there, and Canonical today describes it as "the fast, open and secure display server for any device."

Why a 13-year-old project still matters

Mir still underpins several Canonical products and community shells. Ubuntu Frame is a fullscreen shell for kiosks and signage. Miriway is a lightweight desktop shell. Ubuntu Touch, running via Lomiri, is migrating its session to Mir 2.x, with a first demo targeted for end of October 2026, the same window 2.31 lands in.

The Mir family is growing too. Miracle v0.11.0 is a Mir-based compositor with workspace overviews, and its v0.12 build will reportedly focus on "wobbly windows", a small reminder of how much is being built on this shared foundation.

The bigger picture: Mir tracks Ubuntu release cycles. 2.31 sits alongside the Ubuntu 26.04 LTS series and is also being built for 26.10. Debian needs to promote an older Mir to unstable before adopting 2.30, and that mandatory Rust build dependency may hold some distros back temporarily. It's a practical wrinkle for cross-distribution users who want the latest of everything.

Not much of a stretch to call this a disruptive release would be wrong, then. With no ABI bumps and no removed APIs recorded for 2.31, it's clearly a stabilization cycle. The big architectural shifts, from Rust integration to foreign-surface capture and output configuration, were introduced in earlier 2.x releases and are just being refined now.

What to do next

If you want to test it yourself, Mir publishes a "How to test Mir for a release" guide, and the release pipeline posts a comment pointing testers right at it. The repo shows a healthy mix of Canonical maintainers and frequent first-time contributors, which is usually a good sign for a stabilization cycle.

Head here to the GitHub release page.