madsmtm/objc2

Minimum Supported Rust Version (MSRV) Policy?

madsmtm opened this issue · 5 comments

madsmtm commented

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"):
  • See libc discussion: rust-lang/libs-team#72
  • See also winit discussion: 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 commented

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

Lokathor commented

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.

  • ❤️2
  • 👀2
matklad commented

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)

  • 👀1
notgull commented

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).

  • 👀1
madsmtm commented

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