[RFC] Alternative new MSRV policy #523
Conversation
|
I'll wait to r+ in case there are more tweaks to the proposal, but I plan to approve this RFC. |
adamgreig
changed the title
| update to a dependency might violate a published crate's MSRV. | ||
|
|
||
| So far, the WG has received very little feedback from any users who rely on the | ||
| relatively old MSRV, and so most of their use cases have been hypothetical. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
As a note: The requirements for voting majority are:
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
added
the
decision-accepted
|
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+ |
|
Build succeeded: |
526: Update MSRV policy r=thalesfragoso a=adamgreig This PR updates our MSRV policy in line with RFC #523. Co-authored-by: Adam Greig <[email protected]>
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