Minimum Supported Rust Version (MSRV) Policy?

[madsmtm]

This library should probably settle on some kind of MSRV policy, I would like some input on that?

A few options:

• N-3
• 6 months timeframe
• 12 months timeframe
• Pick a stable version, and then stay there until next major version. Allow feature flags to have higher MSRV.

Notes:

• Does MSRV bump constitute a breaking change?
• GCC Rust will support 1.40 to start with
• mrustc supports 1.54 (as of july 2022)
• We could have different policies for the different crates (e.g. objc-sys supports "N-10" while objc2 supports "N-3")
• Downside is that features like extern "C-unwind" would take longer to make default
• Distribution version (here supporting the "this package is possible with distribution-provided cargo/rustc"):
  • Ubuntu
  • MacPorts
  • Debian
  • Alpine
  • Fedora
• See libc discussion: MSRV policy for libc crate rust-lang/libs-team#72
• See also winit discussion: Minimum Supported Rust Version rust-windowing/winit#1075
• Given that this package is mostly used on macOS, where users will be getting the rustc using rustup or MacPorts, maybe the situation is a bit different?
  • Would work if we're using newer rustc features, doesn't if we're using newer cargo features
• Our dependencies (cc, libc, malloc_buf and uuid) would have to have a policy that matches ours!

[madsmtm]

See also rust-lang/libs-team#72 (comment) on how to check with -Zminimal-versions in CI, if that becomes necessary

[Lokathor]

I would vote for 12 months timeframe, no more. I made some strong statements about a fixed MSRV for bytemuck and tinyvec, and it's not impossible to stand by them. but it's inconvenient to stick with them eternally. A rolling window lets you eventually adapt to rust updates without cfg all over your crate, while a large rolling window lets you stay compatible with linux distros.

Even SDL2, famed for its long term compatibility, will bump its requirements over time.

[matklad]

while a large rolling window lets you stay compatible with linux distros.

Something I've learned is that 12 months might not be enough for some LTS-style situations.

• 12 months is too fast for Debian stable
• curiously, tokio has 6 months MSRV, but also 1 year LTS releases, which together effectively gives 18 months MSRV

(note: the above is purely descriptive, not prescriptive one way or another)

[notgull]

For my crates, I usually try to keep the MSRV at or below Debian Stable, but I don't think that will be desired or even possible for this crate. As it's "experimental" for the time being, I think it'd be fine to have an undefined MSRV. But, eventually, it would be nice to pin it to either a timed MSRV (12 months is usually fine) or some distro's Rust version (Debian Testing uses 1.56 as of the time of writing).

[madsmtm]

Any bump will also have to be within Firefox' MSRV, if we want wgpu to use icrate: https://github.com/gfx-rs/wgpu#msrv-policy