Minimum supported Rust version policy?

[japaric]

Now that embedded Rust has reached the stable channel I think we should consider setting an org-level "minimum supported Rust version" policy. By "minimum supported Rust version" I actually mean "how many stable Rust versions should the latest minor version of a (pre-1.0) crate support?".

For example, we could support only the latest stable release; meaning that once a new stable version of Rust, e.g. 1.32, is out we can issue a new minor version of e.g. cortex-m that no longer compiles with Rust 1.31 and requires >=1.32 to build. Note that this doesn't necessarily mean that we'll (artificially) bump the required Rust version whenever we release a new minor version; however, the user should be aware that moving to a new minor version of one our crates may require a compiler update if they are using an old stable compiler.

I haven't seen a common trend like "we only guarantee that the three latest stable Rust releases are supported by our latest crate release" in the ecosystem but I have seen some crates, like syn, that go great lengths to support very old compilers (e.g. syn supports Rust >=1.15). We could do something like that as well.

Thoughts? Should we provide (and document) any guarantee about the Rust versions a crate support? Should we try to make that guarantee uniform across all our crates? What would be a reasonable policy? Last 3 releases (one nightly -> beta -> stable cycle)? 2 (one quarter)? always >=1.31 (>= 2018 edition)?

[therealprof]

I would make this more of a soft policy. On one hand it's nice to have to have software that will compile with older compilers (although I do not think that "older" compilers are actually a big thing with Rust unlike other languages, due to the stability guarantees and ease of deployment) on the other hand I do expect new Rust versions providing new language features which are very important for us to enable new features or remove ugly workarounds and in that case we do not want to be bound to having to support older compilers for a long time.

Why not simply guarantee the operation on the latest version and if we decide to implement something that is not backward compatible, bump the minor version so people need to deliberately opt-in to using the newer compiler version (it also seems somewhat likely that making use of new compiler version features might be a breaking change anyway).

[korken89]

I agree with @therealprof here, as we want to get rid of workarounds over time.
And bumping the minor version does not feel overly intrusive so I'd go for that.

[japaric]

it also seems somewhat likely that making use of new compiler version features might be a breaking change anyway

Bumping the required compiler / Rust version is a breaking change as per semver (*). I don't think "stop following semver" is up for discussion. This policy is more about limiting the rate of "churn" in the crate ecosystem.

To give a concrete example: the cortex-m crate. This crate compiles on >=1.30 right now. Let's say we want to hard-enable of the const-fn feature so we make a new minor release (v0.6.0) that bumps the version requirement to >=1.31. Very importantly, we can not use the semver trick to bridge these last two minor releases (v0.6 and v0.5) because of the different compiler version requirement. Also, these two minor versions can't be linked together because of singletons (Peripherals) so with the new release we have effectively split the ecosystem in two parts that can't work together: crates that are using v0.6 and crates that are still using v0.5. With an "only the latest stable release is supported" policy, we are allowed to split the ecosystem every 6 weeks. With other policies like "last two stable releases are supported" we would, in the worst case scenario, split the ecosystem (far) less often.

(*) Which is why I think that regardless of what policy (if any) we pick here we should (a) document the compiler version support of each crate, (b) have a builder (e.g. rust: 1.30) that checks that the crate compiles for the documented minimum supported version and (c) document changes in the minimum supported compiler version in the CHANGELOG.

[therealprof]

@japaric I hear you. I still don't think a hard policy is appropriate here; if an important change pops up we want to be able to figure out a reasonable way to adopt it and that includes a whole lot more work and coordination than bumping a crate version. I don't think this will happen very often (probably not more than once, worst case twice a year) but if it happens in two consecutive Rust releases we don't want to be twiddling thumbs and having to wait until our previously fixed policy allows us to do it. I'd say a reasonable policy here would be a mission statement to avoid unnecessary breakage as much as possible and put a minimum supported Rust release bump under the scrutiny of a member discussion and vote for the main crates.

(*) Which is why I think that regardless of what policy (if any) we pick here we should (a) document the compiler version support of each crate, (b) have a builder (e.g. rust: 1.30) that checks that the crate compiles for the documented minimum supported version and (c) document changes in the minimum supported compiler version in the CHANGELOG.

That makes total sense.

[TeXitoi]

Considering rust version bump as a semver breaking change is not wildly accepted. For example, you can see clap's policy: https://github.com/clap-rs/clap#minimum-version-of-rust

IMHO, requiring recent compiler version for embedded is much less problematic than for CLI: CLI are generally integrated in linux distribution via packages, compiled using the rust version present in the package manager. Embedded systems don't have to my knowledge this kind of constraints.

Now, you don't want to adopt the newly released stable toolchain without waiting a bit. Supporting the previous stable seems an OK compromise (6 weeks to use the new feature).

Now, I'd personally prefer to not break the ecosystem using the semver trick and requiring a more recent toolchain for a pre 1.0.0 patch version.

[eddyp]

How about using the 2018 edition version as the base version on which the lib should work, unless the crate needs features which appeared post 1.31?

[japaric]

@therealprof in general, not having a policy means we have to explicitly get the whole responsible team together and discuss the change before making a decision. Having a policy means one can just send a PR, say "this follows our established policy" and be done with a single review. Of course, a policy may not be the right call 100% of the time; in those cases we'll have to discuss what to do but that will be a special case so having a policy would still reduce the amount of required coordination.

@TeXitoi clap is a 1.0 (2.0, actually) crate. Crates that have reached 1.0 shy away from bumping the major version (semver bump) because that's seen as a Bad Thing (TM) from a branding / marketing / "stability promise" perspective. (Also see rustc / Rust)

pre-1.0 crates, which is what we are discussing, will usually bump the minor version (semver bump) when the minimum supported rust version (MSRV) changes. See https://users.rust-lang.org/t/rust-version-requirement-change-as-semver-breaking-or-not/20980/2

Now, you don't want to adopt the newly released stable toolchain without waiting a bit

Exactly, and this can be encoded in a policy like "MSRV is never higher than latest stable minus 2" (or 1, or whatever seems appropriate).

Now, I'd personally prefer to not break the ecosystem using the semver trick and requiring a more recent toolchain for a pre 1.0.0 patch version.

Sorry, I'm not sure I completely understand this sentence. Could you give an example of what you mean?

@eddyp most of our no_std crates effectively have an MSRV of 1.31 (and 1.30 in some cases) but this is neither documented, tested or guaranteed.

unless the crate needs features which appeared post 1.31?

but when should the MSRV be increased? Right after the feature makes it way to the latest stable? Or should we wait a bit? A policy would answer those question.

[therealprof]

@therealprof in general, not having a policy means we have to explicitly get the whole responsible team together and discuss the change before making a decision. Having a policy means one can just send a PR, say "this follows our established policy" and be done with a single review.

Fair enough. In that case my vote would still be on the policy I laid out in #285 (comment), i.e. guarantee only that it compiles with the latest stable and document which version that is and if a change requires a newer stable version we'll note that requirement and bump the minor version to alert users to that fact that this will require a newer rust version. We can easily test for the requirement, too, by simply requesting a specific stable version in the .travis.yml file.

[adamgreig]

I am pro having a MSRV policy to ensure we document and test what the MSRV is for each wg crate. For the time being I wonder if we're best waiting a few releases and seeing how we get on -- so far there's only been zero (or sort of one) Rust stable release since we could compile on stable at all, so we don't really have much experience with how often we might want to bump this or what the ecosystem implications will be.

I'd be happy to say "compiles on latest stable for now; re-evaluate MSRV policy in 1 year", or equally happy to say "must compile on 1.31, re-evaluate in 1 year".

[japaric]

I have written a policy based on the comments so far: #304