From 0e817a19837b38d31acf8e76e9abaa91d5456869 Mon Sep 17 00:00:00 2001 From: Ed Page Date: Wed, 10 May 2023 23:31:27 +0200 Subject: [PATCH] docs(ref): Clarify MSRV is generally minor For the second time in the last week or two, I've seen the wording of cargo's semver documentation used to justify pushing back against treating MSRV bumps as minor changes. See https://github.com/time-rs/time/discussions/535#discussioncomment-5863587 The current wording makes it sound like "major" is the default stance but the [general consensus seems to be around "minor"](https://github.com/rust-lang/api-guidelines/discussions/231). I held back from changing from "possibly major" to minor" for now as the above linked policy isn't official yet and it leaves it open for crates to treat it as major. --- src/doc/src/reference/semver.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/doc/src/reference/semver.md b/src/doc/src/reference/semver.md index 5ce9b5dd4df..5a53a655464 100644 --- a/src/doc/src/reference/semver.md +++ b/src/doc/src/reference/semver.md @@ -1251,7 +1251,8 @@ projects that are using older versions of Rust. This also includes using new features in a new release of Cargo, and requiring the use of a nightly-only feature in a crate that previously worked on stable. -Some projects choose to allow this in a minor release for various reasons. It +It is generally recommended to treat this as a minor change, rather than as +a major change, for [various reasons][msrv-is-minor]. It is usually relatively easy to update to a newer version of Rust. Rust also has a rapid 6-week release cycle, and some projects will provide compatibility within a window of releases (such as the current stable release plus N @@ -1530,3 +1531,4 @@ document what your commitments are. [struct literal]: ../../reference/expressions/struct-expr.html [wildcard patterns]: ../../reference/patterns.html#wildcard-pattern [unused_unsafe]: ../../rustc/lints/listing/warn-by-default.html#unused-unsafe +[msrv-is-minor]: https://github.com/rust-lang/api-guidelines/discussions/231