Consider Max MSRV Policy

[cwfitzgerald]

At the last maintainers meeting, and in #8923, it came up that users would want to have our maximum MSRV be lower than "current stable". Currently we will update whenever we want, up to and including current stable.

• In the maintainers meeting, it came up that rerun is using "stable - 2", which means they need to wait to adopt new wgpu versions until 2 versions have passed.
• In Support for binding arrays of RT acceleration structures #8923 @kvark mentioned that nix only currently packages 1.91.

We should figure out if we should have an explicit "max MSRV" policy to prevent possible issues with users. If there are any other users who are having issues with our MSRV, please shout.

[inner-daemons]

I would be in favor of stable-2 or even stable-3. I definitely don't think we need to always be living on the edge.

[cwfitzgerald]

cc @Wumpf

[nicoburns]

This is definitely an issue for the Servo project (see https://servo.zulipchat.com/#narrow/channel/263398-general/topic/Time.20to.20increase.20our.20MSRV/with/571270070). Note that we currently have an active discussion on whether we are able to update our MSRV to Rust 1.88 (we're currently on 1.86) which would enable us to use WGPU 27. and that's not even the latest wgpu version!

Our main constraint here is newer versions of rustc dropping support for older versions of LLVM, and some Servo users (notably the Open Harmony project) not having newer versions of LLVM available.

---

It might be worth considering an "only bump when actually needed" kind of policy. I wouldn't want to prevent wgpu from implementing new features because they're waiting on a rustc bump (even if that bump is to a really recent version). But I would also definitely prefer a lower MSRV if it's easily achieved.

As an example of how I'm thinking about things: some of the crates I use depend on fearless_simd. That crate upgraded to Rust 1.86 (pushing it's dependents to also upgrade) almost immediately after 1.86 was released because Rust 1.86 included improvements to SIMD intrisinsics and const evaluation, use of which meaningfully improved the libraries implementation and cannot be polyfilled. But I would expect the next release to be not much higher MSRV because recent rustc releases have mostly included minor improvements that might be a small ergnomics win but aren't really necessary.