Document Minimum Supported Rust Version

[sunjay]

Need to put some thought into this and then add a note in the README.

Relevant links:

• https://github.com/redox-os/rusttype#minimum-supported-rust-compiler
• https://gist.github.com/alexheretic/d1e98d8433b602e57f5d0a9637927e0c

[myrrlyn]

It's 1.36.0 on current master, as 1.35.0 had not stabilized MaybeUninit, which appears in arrayvec 0.5.1.

Draft Patch

README.md

Place this section anywhere:

## Minimum Supported Rust Version

The current minimum Rust version is `1.36.0`. Raising the MSRV will be done in
minor-version releases. If you work with a fixed version of Rust, the version
format

```toml
# Cargo.toml

[dependencies]
turtle = "~> Major.minor"
```

will ensure that your dependency on `turtle` will never be broken by an MSRV
increase without your explicit action. If you track latest stable Rust, then you
can depend on `turtle` without any extra work.

rust-toolchain

- stable
+ 1.36.0

[sunjay]

What are your thoughts on making the minimum supported Rust version for turtle the latest stable version of the compiler? The links in the issue description point to another crate that does that.

I'm interested in thoughts about this from the perspective of turtle being a crate for teaching Rust, not a really general crate that's going to be used by a lot of people in the ecosystem. It might not actually be that useful to pin to a particular version of Rust. Turtle also doesn't release very frequently or make breaking changes, so if someone is required to use an older compiler for some reason, they can always choose a version of turtle from a release or two ago.

At least at face value, there doesn't seem to be a big downside to allowing the turtle crate to continue using features from the latest stable compiler. I haven't given this a great deal of thought though, so I'm interested in what other people think.

[myrrlyn]

The "minor versions may increase MSRV" policy is essentially a formalism of what "compiles on stable" actually means. Writing patch-release changes that depend on changes from language minor versions is a code smell against Semver, so any internal change that relies on a newer language minor version is in general going to be a minor version release of your library as well.

In my experience, the only difference between putting stable in rust-toolchain and an explicit MSRV number is that you have visibility into what part of new language releases you're using.

You're probably right in that turtle should not pin an MSRV in its rust-toolchain, though, since that forces rustup to grab a specific snapshot rather than a release train when people clone the repository and run examples. I'd add it to the CI version set instead, and when you need a new language release, you get an automated checkpoint to tell you to put it in your changelog.

To me, the difference between a documented MSRV (even if it keeps rising! There's no requirement to lock against a language release for a long time unless you explicitly require LTS stability) and stable is that stable means "you probably have to run rustup update before using this", while an MSRV means "as long as you ran rustup update vaguely recently, you're good".

[sunjay]

I agree with all of your points and I am pretty much ready to adopt this. Like you said, I would change the CI (in azure-pipelines.yml), not the rust-toolchain file itself. (We delete the rust-toolchain file in CI anyway.)

---

I had more to say on this, but I deleted the rest of my comment because I want some more time to think about this. Anyone else is welcome to join this discussion if they have thoughts.