Establish MSRV policy and set rust-version in workspace Cargo.toml

[glamberson]

Hey all. I wanted to open this as a broader discussion separate from #1153, since this is really a project-level question rather than a single-PR concern.

IronRDP doesn't currently have a documented MSRV policy or a rust-version field in the workspace Cargo.toml. The rust-toolchain.toml pin ends up serving as the de facto MSRV, but that's not really what it's for, and it makes life harder than necessary for downstream consumers who are packaging for Linux distributions.

Where things stand

The current master compiles on Rust 1.85. PR #1153 migrates to edition 2024 (also 1.85 floor) and pins the toolchain to 1.94.0. The only post-1.85 language feature I found in #1153 is is_multiple_of() (stabilized in 1.87, ~10 call sites from clippy suggestions). Without a rust-version field, there's no way for downstream tooling or packagers to know that the actual requirement is 1.85/1.87 rather than 1.94.

The distribution landscape

For context on why this matters to me specifically, here is what the current stable distributions ship:

Distribution	Rust version
Debian 13 (trixie) stable	1.85.0
Debian 13 backports	1.90.0
Fedora 43 (stable)	1.90.0
RHEL 9 rust-toolset	1.88
AUR / rolling	1.94

No current non-rolling distribution ships Rust 1.93+. My own project (lamco-rdp-server) already declares rust-version = "1.88", so I'm not asking for extreme conservatism here. But the ceiling I can work within is 1.90: that's what Fedora 43 and Debian 13 backports provide. An MSRV above 1.90 breaks both of those, and Debian 13 base (1.85) is the floor for non-GUI builds where iced/wgpu are feature-gated out. Debian 12 ships Rust 1.63, so there is no fallback to an older Debian.

Other downstream projects that would be affected: Marc-Andre Lureau (@elmarco)'s qemu-rdp/ironrdp-fedora (Fedora-packaged), cosmic-ext-rdp-server, and devolutions-gateway itself is on toolchain 1.90.0.

Proposal

1. Add rust-version to the workspace Cargo.toml. This is the standard way to communicate the actual minimum to Cargo's MSRV-aware resolver and to downstream packagers.

2. Pick a policy and document it. Some options:

   • Edition floor: MSRV = edition minimum (1.85 for edition 2024). Very conservative.
   • N-2 stable: Current stable minus two releases (~3 months lag).
   • Calendar-based: Stable from 6 or 12 months ago. This is what tokio does (6 months).
   • Feature-driven: Bump only when a specific language feature or dependency requires it.

   I don't have a strong opinion on which policy, but any documented policy is better than none. It lets downstream consumers plan rather than guess.

3. MSRV CI job. A build on the declared rust-version in CI keeps it honest. Without this, the declared MSRV drifts as new code lands.

The sspi factor

I know you're all well aware of the sspi pre-release dependency situation (#537, #515, #504). I'm not raising it to re-litigate it, but the combination of 26 exact-pinned RC crates and an undocumented MSRV creates a lot of friction for anyone trying to package IronRDP for a distribution. A clear MSRV policy helps separate the things we can plan around from the things we can't.

What I'm asking for

The concrete ask is small: add rust-version to Cargo.toml and write down what the policy is. The actual minimum the code requires after #1153 is 1.85 (or 1.87 with is_multiple_of()), well within what every current stable distribution can handle. Making that explicit costs nothing and helps everyone downstream. For what it's worth, my own project already requires 1.88 (driven by iced/wgpu), and I review that number weekly, pushing it as high as I can while still covering current stable distributions. I'm not asking IronRDP to be more conservative than I am. I just need IronRDP to not jump past what distributions actually ship.

Happy to submit a PR for the rust-version field if that's useful.

Regards,

Greg Lamberson
Lamco Development
greg@lamco.io