[RFC] Alternative new MSRV policy

[adamgreig]

This RFC is an alternative to #449, as discussed in this week's meeting (logs). It proposes essentially removing our MSRV policy; the new requirement would be "build on current stable Rust".

I would specifically like to solicit feedback from anyone who benefits from our current MSRV policy (generally old Rust versions, at the least no newer than stable-3, specifically documented and tested against, and updated infrequently). At the moment I'm only directly aware of one use-case for a custom target which requires a custom rustc/llvm build. It would be really useful to hear from people who for whatever reason need to use an older Rust version, and to understand a bit more about why they need that and how this change might affect them.

Rendered

[jamesmunns]

I'll wait to r+ in case there are more tweaks to the proposal, but I plan to approve this RFC.

[eddyp]

I take this lack of feedback as a temporary situation caused by the immaturity of the current ecosystem, but l expect this will change in the context of something like Sealed Rust where the version might be frozen for years.

Is it commonly agreed that the policy will change once such a situation is close to becoming reality?

Similarly, if a create becomes 1.0 shouldn't there an expectation that the msrv to be kept the same for all 1.x versions?

[adamgreig]

We can certainly review the policy in the future, especially if things seem to have settled down further. Sealed Rust is sort of its own thing I think; it would be a commercial offering with commercial support for its MSRV and library versions, so we might not expect to support it as a volunteer-run WG. Or, we might, if it's useful, or perhaps a commercial organisation could help maintain WG support.

Even 1.0 crates would have the same issue with dependencies - it's not generally considered a semver-breaking change to require a new stable feature, so (all hypothetical) cortex-m 1.0 could rely on some bitfields 1.0 and have an MSRV of 1.48, then bitfields 1.0.1 comes out with an MSRV of 1.50 -- what does cortex-m do? In this policy, it just now has an MSRV of 1.50. In other policies we either have to pin bitfields==1.0.0 and force users to deal with the issues, or we'd have to release cortex-m 2.0 just to increase our MSRV, which isn't great either. Or, we forbid using any dependencies not controlled by the WG (or vendor them all ourselves). I think the problem is basically no different with 1.0 crates as with any other version.

[jamesmunns]

I want to agree with @adamgreig here, as someone working on "Sealed Rust", I don't think it makes sense to offer LTS as an open source group, but rather if there is desire for an LTS version tied to a specific (qualified) Rust release, for there to be a separate effort on that once the demand materializes.

For these libraries to be useful for safety critical applications, they would need to be qualified anyway, so the open source, rapidly iterating version would not be useful as-is anyway.

[jamesmunns]

As a note:

The requirements for voting majority are:

• 10/20 approvals before 2020-11-21 (not met)
• 7/20 approvals between 2020-11-21 and 2020-12-05 (met)
• 2/20 approvals after 2020-12-05

So, as of yesterday, we are "clear" to approve this RFC. @adamgreig do you want to leave this open until the next meeting to give a "last call"? Or should we go ahead and merge?

[therealprof]

I just noticed we were missing the labels to actually block the merge until a decision has been made. 😅

I don't think we should deviate from our rules and just go ahead and merge this now.

bors r+

[bors]

Build succeeded:

• dummy