Merge #523

523: [RFC] Alternative new MSRV policy r=therealprof a=adamgreig

This RFC is an alternative to #449, as discussed in this week's meeting ([logs](https://freenode.logbot.info/rust-embedded/20201110#c5777770)). 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](https://github.com/rust-embedded/wg/blob/new-msrv/rfcs/0523-msrv-2020.md)

Co-authored-by: Adam Greig <[email protected]>

Author: bors[bot]

rfcs/0523-msrv-2020.md

@@ -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.