Re-evaluate WG wide MSRV policy

[jamesmunns]

No description provided.

[adamgreig]

Current policy is: https://github.com/rust-embedded/wg/blob/master/ops/msrv.md

ref: #304 #285

[adamgreig]

Currently our policy suggests the highest allowable MSRV is stable-1. Given the stability we want to maintain with the upcoming 1.0 releases, I think we should consider changing this to stable-2 or stable-3.

The current policy has a separate MSRV per crate. This is probably the only manageable approach, but it's worth bearing in mind that many of our crates depend on each other, which will impact MSRVs: bumping r0 would require also bumping cortex-m-rt, for example.

I suggest we amend the policy to include something along the lines of:

• Each crate specifies the lowest possible MSRV that can build the crate
• When a PR is being considered that uses features only available in a newer Rust version, it can include increasing the MSRV up to the rust-embedded limit (stable-N, tbc), but this change is reviewed as part of the PR to balance the cost/benefit of increasing the MSRV for this specific crate
• Increasing the MSRV for a crate requires a vote by the crate's team, not just a single approval

Additionally @jonas-schievink mentioned that we might want to reconsider making updating the MSRV a breaking change requiring a semver bump; apparently this is not commonly done in other Rust projects.

[posborne]

Most of these suggestions seem pretty reasonable to me. A few notes:

• I agree that it can get complicated managing MSRV with multiple dependent crates but I don't see a way around it.
• I would be against changing the policy related to making an MSRV change not require a semver bump. As an application maintainer, having to work around breakages when one does a cargo update is frustrating, especially if the rust version is only a little old. That being said, it is the state of affairs that in some cases dependent crates won't follow these rules and decisions need to be made. We ran into this here the other day: MSRV 1.31 rust-sysfs-gpio#59

[Disasm]

The same happened with riscv due to the bare-metal patch update (fix: rust-embedded/riscv#33).
I don't think that having MSRV on non-leaf crates or crates with lots of foreign dependencies is a good idea.

[thejpster]

Here's my hot take. Careful not to burn yourselves.

I don't care about old versions of stable Rust. The compiler is free. The compiler moves fast, on a regular cadence. Updating is relatively painless. I posit that anyone who does care about old versions of stable Rust is in a commercial environment, in which case, I invite them to a) cargo vendor everything and b) pay someone to backport fixes. We should not operate like Red Hat Enterprise Linux, as we don't get the subscription fees. We should operate like Debian Testing. Using a rustc compiler from last year is like using Windows XP - OK, but you really need to unplug that think from the Internet, because the rest of us have moved on already.

So what I would do is:

1. define "stable - X", to mean X minor releases prior to the current stable version of rustc. For example, if stable is 1.42, then stable - 2 is 1.40.

2. Set our MSRV to stable - 2. As in the literal string stable - 2, not what ever value that happens to evaluate to today. Lazy evaluation if you will.

3. Fix rustup and/or our travis scripts to install stable - 2. Whether we grok the version output of rustc and go and rustup install one that's two versions older than that, or we patch rustup to understand the concept of stable - 2 I don't mind.

4. Offer to fix any issues where the crate doesn't build on stable - 2 but go no further than that.

5. Start using major.minor.patch semantic versioning to describe our actual API changes - the bits our users touch on a regular basis - rather than some ill defined concept of maybe 0.001% of our users using last year's compiler are going to have a bad day. If an upstream crate changes something, we only have to worry about the API impact, not whether they now use a feature that was added six months ago. This will require our upstream crates to not be too aggressive in picking up features from the very latest stable, but 12 weeks (i.e. two releases) seems reasonable, as we don't see a huge amount of upstream churn, and it's certainly much less of an issue than setting our MSRV 72 weeks back (i.e. 12 releases) and having to do a bunch of work if anyone starts using a feature stabilised in the last year.

TL;DR: Embrace the release train. Forget about the past. Set the MSRV to stable - 2 and roll with it.

[teskje]

I posit that anyone who does care about old versions of stable Rust is in a commercial environment

I wonder if this is true? What about users that rely on their OS's package manager for their Rust install? Debian stable currently includes Rust 1.34, which is pretty old. There might be reasons for not wanting to switch to rustup to get newer versions (though not sure which these might be).

On the other hand, if we want to support such Debian-stable users, our "maximum MSRV" (MMSRV?) would need to be 1.34. Committing to stable - 2 does not help these users much in the long run.

If the consensus is that we don't care about supporting old Rust versions, then I agree setting the MSRV to always be stable - X everywhere would make sense. It's important that we can make the CI understand that too, so we won't have to generate new commits every 6 weeks just to bump the MSRV. I guess not being able to do that easily is the main reason for our current MSRV policy.

One more thought: What specifically is the reason to limit ourselves to stable - 2? If we assume that all users can simply update their Rust compiler whenever, wouldn't it make more sense to set the MSRV to stable instead? This would have the two benefits that a) we won't have to wait 12 weeks before we can use a new feature (think about when const generics finally land!) and b) CI testing would be significantly simpler.

[Sh3Rm4n]

Debians rust version has more to do with the fact, with which compiler version the rust packages are build for that specific Debian release. This is important for users and developers of rust programs packaged for Debian.

If I developed on Debian, I would install the latest rust compiler via rustup anyways and as embedded-rust is not developing user-software, which is planned to be packaged for Debian, this should not be our concern.

[thejpster]

I didn't go with stable simply because it takes a little time for the new version to be downloaded by everyone and because it's useful to let newly stabilised features settle for a while (in case the beta period didn't find all the bugs).

I'm relaxed about stable - X for any small value of X.

[tarcieri]

I posit that anyone who does care about old versions of stable Rust is in a commercial environment

I'm a fan of aggressive MSRV, but I'll note there's another reason why people might be on older releases of Rust: because they're using experimental codegen backends created by people who who don't have time to continuously update their rustc forks to the latest Rust release.

Ideally people would upstream all of these backends, and on a longer scale that's hopefully what happens, but that's also a lot of work.

[dbrgn]

For libraries, a fixed MSRV is very important if users of the library might want to guarantee a fixed MSRV. Authors of a GUI application that want the application to be easy to build for Debian will hate it if libraries require Rust versions newer than what the Debian build system offers.

I'm the maintainer of tealdeer which is also packaged in some Linux distributions. I really try hard to guarantee a fixed MSRV, but it's a royal pain if libraries suddenly require newer Rust features (often accidentally) in a patch version. Essentially, every time I run cargo update during maintenance (which should usually result in a patch release of tealdeer) there are some deeply nested dependency suddenly requiring a newer Rust version in a patch update because of some minor and totally unimportant detail (like omitting the lifetime in a constant).

For libraries purely targeted at embedded, the situation is probably different. Users of HALs and PACs will not care much about the version of Rust provided on Debian.

For development tools (like itmdump) and generic no-std libraries (like heapless) this might not be the case though. If Debian wants to package itmdump, requiring a very recent version of Rust might be inconvenient.

[thejpster]

If Debian wants to package...

Debian stable specifically. Testing and Unstable are on 1.42. Stable is on 1.32. I'm not sure how many new packages get added to stable after release ... are there many?

I think if anyone is building with rustc on Debian, I kind of expect them to use the crates that are packaged with Debian. If ripgrep, say, suddenly gets an MSRV bump because a library it uses now uses a new feature, that isn't an issue for a Debian Stable user who runs "apt install ripgrep", because the version of ripgrep in Stable will always be a version that builds with the rustc in Debian Stable. If you took the Debian rustc and tried to build ripgrep master, I think it's only fair to expect issues. The same applies to using RHEL in general (hence Software Collections, but never mind that). If you want to build your own software, I would tell Debian Stable (and RHEL) people to get their own compiler - the one in the OS is for the OS and is deliberately out of date.

which is also packaged in some Linux distributions...

Yes, this is a pain. But I don't think MSRVs set back to whichever OS has the oldest and crustiest version of rustc and major version bumps every time we want to use a 12 month old feature that isn't in the 18 month old compiler is a price that's fair to inflict on the entire community - especially those who are primarily building Embedded Rust software that isn't packaged for Linux distributions.

Perhaps to make things a little less painful for those who target old OSes, we could teach rustup about the version that Debian Stable is shipping. At least then for those who do want to use that as their MSRV, there would be an easy way to get rustup to fetch it and build something with it.

[thejpster]

experimental codegen backends

Oof yeah. Again, I appreciate it sucks for them but again I don't know if avoiding stabilised features for 18 months is a price worth paying.

[dbrgn]

if avoiding stabilised features for 18 months is a price worth paying

Having a stable MSRV per semver version does not necessarily mean that you need to target an ancient version of Rust, it just means that the MSRV will not change in a patch release (and ideally not even in a minor release). I wasn't complaining about people raising their MSRV, that's perfectly fine. I was complaining about MSRVs being raised in patch releases, usually without even a mention in the changelog.

A stable MSRV means that as long as a user of the library does not bump the version in Cargo.toml, compilation will not break.

But again, in the embedded ecosystem things may be different and using a moving rustc target may be perfectly fine. I don't have a strong opinion in this case, just wanted to add some counterpoints to "only enterprise customers will care about MSRV".

[jamesmunns]

I've opened a Draft RFC here: #449

[BartMassey]

Please see #523 for an alternate policy proposal that was ultimately adopted.

[BartMassey]

Closing this as part of the 2024 triage.