Decide on an MSRV Policy

[emmatyping]

For compatibility with the many platforms CPython ships on, we should select a minimum supported Rust version for CPython.

Things to consider when doing so:

• Going backwards in versions might be hard, as new features could be critical to how we design abstractions.
• 1.85 introduces Rust 2024, which has several nice improvements
• We should consult with Linux distribution maintainers as part of this selection

[youknowone]

Rust 1.88 stablized let chain, which enhance coding experience for complex if statements

[epage]

https://doc.rust-lang.org/cargo/reference/rust-version.html explores MSRV considerations.

Huh, something I'm not finding on that page is discussion of development MSRV vs production MSRV. What this means is what versions are needed or allowed during development vs what is needed just to build a production binary. This distinction is important for a couple of reasons

• If a higher development MSRV is required, then those steps that require it can't be done on the production binary. For instance, if you have a test dependency that requires a higher MSRV, then you can only verify your MSRV for compile time and not runtime.
  • There might be some things where this is fine. For instance, you might feel that not benchmarking on the production MSRV is an acceptable risk, so you can have your benchmarks in a separate package that has a higher MSRV or no MSRV
• If you require your production MSRV for development (e.g. using rust-toolchain.toml file), you prevent people from leveraging new development-time features
  • I also find it annoying when contributing to a project to suddenly pull in a new toolchain

On a related note, you need to decide what version to lint on. Lints change across releases and more can be added. If you turn warnings into errors in CI, this can break CI on a new release. I pin the CI lint job to a specific Rust version and have RenovoateBot post PRs updating it to the latest version. I used to use my MSRV for that but that was annoying in development when I saw a bunch of warnings I couldn't do anything about. It also meant I had to live with lint bugs and live without new lints.

When considering an MSRV, you'll also need to take #3 into account

• It currently lists build-std as required, not just a nice to have, meaning you need nightly until it is approved and stabilized.
• Tracking issue for RFC 2523, #[cfg(version(..))] rust-lang/rust#64796 would make it easier for you and dependencies to support a range of Rust versions. If/when it is stabilized, it will either require that version for the MSRV or only be able to check between that version and previous versions
• There are packages in the community for this but they increase build times and you would have to keep using it until you were willing to bump your MSRV for whatever Tracking issue for RFC 2523, #[cfg(version(..))] rust-lang/rust#64796 allowws

[Kivooeo]

Yes please don't select version below 1.88, I want to use let chains :3

[emmatyping]

I expect the limiting factor will likely be Linux distro support, so I think we should reach out to them first. My inclination is "at most latest - 2 versions, and then pick based on what linux distributions support"

When considering an MSRV, you'll also need to take #3 into account

It currently lists build-std as required, not just a nice to have, meaning you need nightly until it is approved and stabilized.

I think build-std is probably eventually required. We can start without it, and run sanitizers on nightly.

rust-lang/rust#64796 would make it easier for you and dependencies to support a range of Rust versions.

This does seem nice! Perhaps we should add this to #3

[epage]

I expect the limiting factor will likely be Linux distro support, so I think we should reach out to them first. My inclination is "at most latest - 2 versions, and then pick based on what linux distributions support"

I'd recommend also talking to burntsushi as they have done some of the distribution research in the past.