New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Alternative new MSRV policy #523
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,132 @@ | ||
| - Feature Name: msrv-2020 | ||
| - Start Date: 2020-11-14 | ||
| - RFC PR: (leave this empty) | ||
| - Rust Issue: (leave this empty) | ||
|
|
||
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| This RFC proposes an update to the [current MSRV policy], and is an | ||
| alternative to the earlier proposal [#449]. Some of the RFC text is copied | ||
| from that earlier proposal. | ||
|
|
||
| This proposal suggests a significantly reduced MSRV guarantee: all WG crates | ||
| must build on the _latest stable Rust release_ at all times, and it is | ||
| recommended that their main branches are checked to always build on stable via | ||
| CI on both pull requests and regularly scheduled CI runs. | ||
|
|
||
| [current MSRV policy]: https://github.com/rust-embedded/wg/blob/8eb6488fdb16e92e70b074acc2fcf249b3edc70b/ops/msrv.md | ||
| [#449]: https://github.com/rust-embedded/wg/pull/449 | ||
|
|
||
| # Motivation | ||
| [motivation]: #motivation | ||
|
|
||
| <!-- Why are we doing this? What use cases does it support? What is the expected outcome? --> | ||
|
|
||
| As part of the push to take [foundational crates to 1.0] releases, it has | ||
| become necessary to be more exact on our guarantees to support versions of the | ||
| Rust compiler. This discussion [has been contentious] in the past, sparking | ||
| significant discussions in many meetings. | ||
|
|
||
| In particular, it has been necessary to balance the (somewhat opposed) concerns of: | ||
|
|
||
| 1. Some users may find themselves stuck on old versions of the compiler, due to company restrictions, slow moving distribution/package managers, or regulatory concerns. | ||
| 2. We maintain these crates on a volunteer basis, and our time is limited to focus on maintenance | ||
|
|
||
| Our current MSRV policy has been found to have significant flaws around how | ||
| dependencies are managed. Since many WG crates depend on non-WG crates, we | ||
| cannot control the MSRV policy of those dependencies without investing | ||
| additional effort to vendor or fork those crates. Consequently, a non-breaking | ||
| 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. | ||
| Conversely, there are many features in later Rust releases we would like to be | ||
| able to use in crates, and the additional maintenance effort involved with | ||
| checking our crates and all their dependencies support an older MSRV is | ||
| non-trivial. | ||
|
|
||
| The previous proposal to update our MSRV resolved the ambiguity in dealing with | ||
| dependencies, but in a fashion which has downsides of its own and was far from | ||
| unanimously supported. Consequently, this RFC proposes a much simpler MSRV | ||
| policy. | ||
|
|
||
| [foundational crates to 1.0]: https://github.com/rust-embedded/wg/issues/383 | ||
| [has been contentious]: https://github.com/rust-embedded/wg/issues/427 | ||
|
|
||
| # Detailed design | ||
| [design]: #detailed-design | ||
|
|
||
| <!-- | ||
| This is the bulk of the RFC. Explain the design in enough detail for somebody familiar | ||
| with the language to understand, and for somebody familiar with the compiler to implement. | ||
| This should get into specifics and corner-cases, and include examples of how the feature is used. | ||
| --> | ||
|
|
||
| 1. Crates released by the Embedded WG must compile on the most recent stable | ||
| Rust release at all times. If a dependency releases an update which causes a | ||
| published crate to no longer build on the most recent stable release, a new | ||
| version must be released to resolve the issue. | ||
| 2. Individual crates may specify a more restrictive MSRV if the crate's team | ||
| agrees to do so, as long as it is at least as restrictive as this policy. | ||
| 3. It is permissible for specifically-indicated features of a crate to not | ||
| build on stable, to support the use of nightly-only features. All features | ||
| not specifically indicated in the README or documentation must build on | ||
| stable. | ||
|
|
||
| It is recommended that all crates use a CI system to check that a PR does not | ||
| break building on stable Rust, and schedule regular CI jobs to check that a | ||
| newly released stable Rust has not broken the crate's build. Crates may also | ||
| consider regular CI runs against the latest released version of the crate. | ||
|
|
||
| # How We Teach This | ||
| [how-we-teach-this]: #how-we-teach-this | ||
|
|
||
| <!-- | ||
| What names and terminology work best for these concepts and why? | ||
| How is this idea best presented—as a continuation of existing Rust patterns, or as a wholly new one? | ||
|
|
||
| Would the acceptance of this proposal change how Rust is taught to new users at any level? | ||
| How should this feature be introduced and taught to existing Rust users? | ||
|
|
||
| What additions or changes to the Rust Reference, _The Rust Programming Language_, and/or _Rust by Example_ does it entail? | ||
| --> | ||
|
|
||
| We will need to take the following actions: | ||
|
|
||
| 1. Update the [MSRV Operational Notes](./../ops/msrv.md) | ||
| 2. Ensure all crates test the current Rust stable release. It is believed that | ||
| this is already the case, so no further action would be required. | ||
| 3. Update our CI examples and crates to start running scheduled CI tests. | ||
|
|
||
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| This updated policy reduces the burden on Embedded WG maintainers and | ||
| contributors, but at the expense of users who previously relied on our | ||
| conservative MSRV policy. Those users may no longer be able to build | ||
| Embedded WG crates on older versions of Rust, including our foundational | ||
| crates which are widely used in the embedded ecosystem. | ||
|
|
||
| Such users could continue using old versions of crates, fork and maintain a | ||
| version of those crates with a lower MSRV, or contribute to the crates to | ||
| help maintain a lower MSRV if possible. | ||
|
|
||
| # Alternatives | ||
| [alternatives]: #alternatives | ||
|
|
||
| 1. Make no change to our MSRV policy, despite the shortcomings that have become | ||
| apparent around the management of dependencies. | ||
| 2. Accept [#449], clarifying how we manage dependencies while maintaining | ||
| a stricter MSRV policy. | ||
| 3. Accept this proposal, but replacing "latest stable" with "latest-but-one | ||
| stable" or similar. This provides a slightly more conservative level of MSRV | ||
| support for users who can upgrade Rust version but perhaps cannot do so | ||
| overnight. | ||
|
|
||
| [#449]: https://github.com/rust-embedded/wg/pull/449 | ||
|
|
||
| # Unresolved questions | ||
| [unresolved]: #unresolved-questions | ||
|
|
||
| At the moment, there are no open unresolved questions. | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.