open-telemetry
Regulating our MSRV
A recent Dependabot update changes env_logger The biggest risk from my perspective is the MSRV changed to 1.71
While we do have a policy that as long as we're >= 3 behind stable then we don't consider it breaking. However, I'd like us to consider that ferrocene is a certified compiler. Which can now be used in automotive use cases. Ferrocene is essentially Rust, but it's not the latest version. As of their first version it's equivalent to 1.68.2. Our current MSRV is Rust 1.65. Their next certified version is going to skip to 1.76.0.
There's also work on the rust project to deliver a spec for the language which should in theory develop a quicker cycle for getting certified in the future.
I'd propose that we make sure that we're at least compatible with the latest version of ferrocene. What that would look like:
- Current MSRV: 1.65.
- Current Ferrocene Equivalent 1.68.2
- Latest Stable: 1.76
- Today our Maximum MSRV 1.68
Once May 2024:
- Latest Stable 1.79. (Rust is on a monthly release cycle, so 1.77 will be the 3rd most recent for May)
- Ferrocene will be 1.76 compatible
- Maximum MSRV would be 1.76.
Essentially it should be:
min( (Stable - 3 minor revisions), (Ferrocene Supported Rust Version) )
Beyond that though I do think we should only bump if there's a good reason to bump in the name of maintaining compatibility. Good reasons include: Core dependencies require a bump, so long as we're not violating the above rule.
What are your thoughts?
Originally posted by @dependabot in https://github.com/open-telemetry/opentelemetry-rust/pull/1546
EDIT: Updated links to relevant content.
I think our general idea is to keep the MSRV as low as possible. Could you elaborate on what benifit of using a certified compiler? I'd image most of our users use vanilla Rust compiler
Yes i would agree that we don't want to bump the compiler if we do the have to, but that the ceiling for that should be lower than just 3 behind latest stable.
The reason for using the certified compiler is for government regulation purposes, the most cited example is things like automotive. C and C++ follow compliance of a number of ISO standards. The goal for these is have predictable behavior from a spec. Currently the rust compiler itself doesn't have one (yet) but there's active work.
A blog post from late last year talks about some of it https://blog.rust-lang.org/inside-rust/2023/11/15/spec-vision.html Ferrocene blog https://ferrous-systems.com/blog/officially-qualified-ferrocene/
Note that env_logger is only used in examples, so keeping an older version around really doesn't matter.
In many projects I have my MSRV CI jobs set to run cargo check --lib to avoid dev-dependencies like this, but unfortunately that doesn't work for this case because env_logger adopted some Cargo manifest options that break on older Cargo whether the dependency is actually pulled in or not.
Ah so in this case we can also avoid this conflict for env_logger at least by not caring about the examples.