Adopt an official MSRV policy

[notgull]

Earlier, android-activity bumped its MSRV to 1.68.1 in rust-mobile/android-activity#103. This means that winit's MSRV is now effectively 1.68.1 as well. While discussing this in chat, it occurred to me that winit, @rust-windowing and @rust-mobile not have an official MSRV policy.

I've heard conflicting answers from different maintainers about how they enforce the MSRV, ranging from a seven month rolling release window to pinning to various Linux distro's supported versions. I think that a policy should be standardized not only in winit, but also across all repos in @rust-windowing and @rust-mobile. This would prevent the situation linked above from happening.

Edit by @madsmtm to make it visible for newcomers: This has been discussed before in #1075.

[rib]

One notable limitation of cargo's rust-version support is that you can't specify different versions for different targets afaik.

This recent attempt to bump to 1.68 for Android is a pretty good example I think of where it's not really reasonable to impose a single strict policy that affects all backends for Winit because we have good technical reasons why it makes sense on Android to set the MSRV to >= 1.68.

For Android specifically, Rust updated the Android NDK version that they build against for 1.68 which fixed an annoying issue with the standard library being linked against libgcc which is no longer included in recent NDK toolchains. This means that any Android project building with < 1.68 either needs to use a very old NDK toolchain (with different issues) or they need to implement a workaround to link in libunwind as if it were libgcc.

Personally I depend on cargo ndk 3+ across all my Android projects and also for work, and as it happens cargo ndk removed support for the linker workaround now that it shouldn't be needed. In this case I literally can't build on Android with < 1.68 unless I install an older version of cargo ndk which brings with it another set of problems.

So in practice, we're kind of held hostage by Winit's MSRV policy and we're only maintaining the ability to compile with 1.64 in CI based on an old version of cargo ndk that developers wouldn't really use otherwise.

It's a completely artificial constraint that makes it more awkward to maintain android-activity basically because of how Debian is maintained - which shouldn't be relevant for Android development.

Proposal

I think a reasonable solution that works with the limitation that we can only have one rust-version, and should be straight-forward to maintain, would be for Winit's CI setup to be able to allow building different platforms against newer toolchains.

In ci.yml we can update the test matrix so we take 1.64 out of the base rust_version array and add an include section for the matrix to set the minimum test version for each platform instead.

Technically Winit would just keep the conservative rust-version for supporting Debian Sid on Linux but this rust-version wouldn't be enforced in CI on Android.

The final required rust-version from a developer's point of view is the maximum rust-version across all dependencies and on Android it's reasonable that it could require a more recent rust-version.

Winit's CI would be testing the rust-version that Cargo says is required for Android which would likely come from the android-activity + ndk crates.

[kchibisov]

The problem comes from the Cargo.toml rust-version as well, I think the only way to make it work the way you want is to remove the rust-version out of the config and then in the CI builds simply try to build enforcing the versions where it's required maintaining the msrv matrix somewhere in the project we could refer to?

Like the main issue that we need one policy for desktop stuff, and completely different one for the mobile, because mobile requires more recent targets most of the time.

[rib]

I think the rust-version in Cargo.toml can be the minimum version across all platforms (mostly likely whatever Linux needs).

Conceptually the way I see it is that Winit can have one MSRV (specified as rust-version in Cargo.toml) that is only authoritative over the winit crate itself and it defines the minimum version that might possibly be usable if all required dependencies also have the same minimum rust-version or lower.

But app developers or backend developers can choose to pull in deps that optionally require more recent versions of Rust which Winit doesn't need to block.

The rust-version only needs to be concerned with the crate itself that the version is attached too - Cargo will calculate the real minimum version based on the final crates that a project pulls in.

The missing bit I think is just that Winit's CI could take into account that on some platforms there can be other crates that actually require more recent versions of Rust and it shouldn't be assumed that the rust-version for Winit itself doesn't get constrained further by platform-specific dependencies.

Whether or not you can build Alacritty on Linux + Debian should come down to what version of Rust Cargo calculates for all your Alacritty dependencies when building for Linux. Since a crate can only have one rust-version you improve the chances of being able to support Linux + Debian by constraining the winit crate itself to 1.64 by making it possible to support 1.64 but that doesn't mean its necessary to impose the same constraint on the full graph of dependencies across all backends for Winit.

I think we can have the best of both, which is to keep the conservative rust-version of 1.64 for Winit, which can be maintained based on whatever Debian Sid requires but allow backends to pull in dependencies that can constraint the final rust-version more. You just want to avoid constraining it via deps on Linux. CI then just needs to take this into account by making it easy to adjust the version of Rust used to build/test different platforms according to the minimum value calculated by Cargo - taking into account platform-specific dependencies.

[kchibisov]

I think the rust-version in Cargo.toml can be the minimum version across all platforms (mostly likely whatever Linux needs).

Do you know that rust will abort compilation on mismatches? It'll also be hard for contributors to always pass a flag to disable the rust version checks and just 'build'.

The rust-version only needs to be concerned with the crate itself that the version is attached too - Cargo will calculate the real minimum version based on the final crates that a project pulls in.

The thing is about constraining all the deps as well, so users could know that they could build with the given msrv, that's the point why it's msrv, in the end.

Since a crate can only have one rust-version you improve the chances of being able to support Linux + Debian by constraining the winit crate itself to 1.64 by making it possible to support 1.64 but that doesn't mean its necessary to impose the same constraint on the full graph of dependencies across all backends for Winit.

rust-version enforces the requirements on all the deps and it's a must, otherwise it'll become unmaintainable, we must not pull anything that will break msrv.

I think we can have the best of both, which is to keep the conservative rust-version of 1.64 for Winit, which can be maintained based on whatever Debian Sid requires but allow backends to pull in dependencies that can constraint the final rust-version more. You just want to avoid constraining it via deps on Linux. CI then just needs to take this into account by making it easy to adjust the version of Rust used to build/test different platforms according to the minimum value calculated by Cargo - taking into account platform-specific dependencies.

The only way you can do that is if you force 'ignore rust version' checks on CI for Android and force all contributors to android to use ignore rust version flag for cargo, you can't do it differently with the current tooling rust offers for stuff like that.

[rib]

I think the rust-version in Cargo.toml can be the minimum version across all platforms (mostly likely whatever Linux needs).

Do you know that rust will abort compilation on mismatches? It'll also be hard for contributors to always pass a flag to disable the rust version checks and just 'build'.

I had my fingers crossed that Cargo only traverses the optional dependencies that are enabled but haven't double checked that - is that really not what it does? :/

[rib]

Testing this with winit having an optional dependency on android-activity that itself has a rust-version of 1.68 doesn't stop me building for Windows with 1.64, so yeah it seem like Cargo does the right thing and calculates the minimum version based on the crates you currently depend on.

[kchibisov]

The issue will happen right when you start building for android though, it won't allow you to do so.

[rib]

That seems fine too - it's always fine to build with a newer version than the rust-version.

Ignoring the rust-version checks would be applicable the other way around if we set Winit's rust-version to e.g. 1.68 but if you knew it was actually possible to build with 1.64 for Debian then you could tell Cargo to ignore the version checks.

[notgull]

It seems to me that we need to have a two pronged MSRV policy:

• For desktop and web platforms, the MSRV must not exceed the current Rust version available in Debian Testing or Fedora, whatever's lowest.
• For mobile platforms, we need a more liberal MSRV, probably a six-month rolling window would work here?

Would this work for both cases?

[rib]

I would prefer to keep it simple, and not authoritative over platform-specific crates.

CI can test each platform according to the MSRV that Cargo reports for that platform - it doesn't need to be Winit's responsibility to impose what that should be.

The current MSRV policy for android-activity is to (at least) support stable releases over the last three months, but to only bump lazily when there's a reason.

With Android development there's nothing comparable to Linux distribution where we have to cater to people packaging for systems stuck using older toolchains. Even having to wait 6 months before we can use new Rust features is an unnecessary restriction in my view.

For a specific platform like Android I'd much rather start closer to bleeding edge and wait and see if there are specific challenges for Android developers with that policy - as opposed to starting with an unnecessarily conservative policy which just slows down being able to adopt new features but for no real reason.

I think Winit's MSRV policy could be updated to clarify that the rust-version for the winit crate is the minimum possible version, not considering optional dependencies.

Winit's policy could also highlight the specific case that it does guarantee that optional dependencies for the Linux backend are expected to also support the specified rust-version so that Winit can be packaged by Linux distributions.

Essentially the MSRV policy would document that effective minimum rust-version is platform specific.

For other platforms though, I think Winit can leave it up to other crate maintainers to manage platform-specific MSRV policies for platform-specific crates in whatever way makes the most sense for those platforms - which may require newer versions of Rust for some backends, which Cargo will determine and report to users.

Maybe Winit's MSRV policy could link to some of the key platform-specific crates that are most likely to effectively determine the policy for that platform - such as the android-activity + ndk + jni crates on Android.

To allow for this I think Winit would just need to update how it tests different backends so that it uses the rust-version that Cargo reports as the minimum required version. Winit doesn't need to be opinionated here (except on Linux) it can just update its CI when there are MSRV bumps upstream for platform-specific crates.

[kchibisov]

I think what you suggest is overly complicated though. I'd simply use msrv for desktop platforms (excluding orbital), and stable for the rest. Maybe removing the rust_version from inside the winit itself and solely relying on the CI.

[rib]

Yeah, could be simpler and reasonable to just test with stable+nightly for some backends besides Linux.

Dropping the rust-version from Winit considering how it makes sense for it to be platform-specific also sounds reasonable to me - and just relying on CI to ensure Winit builds for old versions of Rust on Linux

[rib]

I don't think I see this as a 'desktop' vs 'mobile' thing though - the outlier in all of this is basically just Linux + Debian I think.

[kchibisov]

I'd still prefer to target more stable platforms with an msrv.

[rib]

In that case I'd still consider a broad split in CI which would treat Linux as a special case (e.g. 1yr rolling), then e.g. have a 6 month rolling msrv for "stable" platforms and platform-specific for others (just built with 'stable')