Skip to content

Latest commit

 

History

History
132 lines (101 loc) · 5.98 KB

0523-msrv-2020.md

File metadata and controls

132 lines (101 loc) · 5.98 KB
Raw
  • Feature Name: msrv-2020
  • Start Date: 2020-11-14
  • RFC PR: (leave this empty)
  • Rust Issue: (leave this empty)

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.

Motivation

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.

Detailed design

  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

We will need to take the following actions:

  1. Update the MSRV Operational Notes
  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

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

  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.

Unresolved questions

At the moment, there are no open unresolved questions.