Change CI to build with Rust 1.32 and document that as MSRV

[adamgreig]

This PR adds a documented MSRV, per rust-embedded/wg#445

As far as I can tell none of the Azure pipelines use Xargo or nightly Rust, so I think this small change should be sufficient, but we'll see what CI makes of it.

[adamgreig]

bors try

[bors]

try

Build failed:

• rust-embedded.cross

[adamgreig]

Looks like we need at least 1.34 for riscv64gc, so I will update the CI to use 1.34 for that target. Not sure what we need to fix the asmjs or x86_64-pc-windows-msvc though, will investigate.

[reitermarkus]

Does an MSRV make sense for a binary-only crate?

[adamgreig]

Okay, looks like riscv64 really needs a very modern Rust. Now we have everything working on 1.32.0 except for:

• riscv64-gc-unknown-linux-gnu: 1.42.0
• asmjs-unknown-emscripten: 1.40.0
• x86_64-pc-windows-msvc: 1.38.0

Does an MSRV make sense for a binary-only crate?

I think it's worth having; I think there are two good reasons:

• Users with older Rust, both today and in the future, are able to build and use cross
  • I appreciate these days lots of users use their own Rust install from rustup so often have the latest version, but already there are people using distro-provided or custom builds for new targets like AVR or Xtensa, and I think as Rust becomes more stable it's likely a larger fraction will use older versions
  • I think some of the main advantages of Rust's careful backwards compatibility promises and widespread use of semver are lost if many useful libraries and executables just keep using the latest stable
• We get to find out if we've unintentionally made a change that requires a much newer Rust. I think today it's not a problem to just increase the MSRV when there's a new feature we'd like to use, since as mentioned many people are tracking stable releases, but at least we have to do it deliberately rather than finding out we've accidentally started using a feature released yesterday.

The current WG policy means it shouldn't be restrictive to have the MSRV, since if a new feature is required we can easily increase the MSRV; it therefore serves as documentation and a check that we're only bumping it deliberately.

Do you think there are reasons to not have MSRV for a binary-only crate compared to a library? I appreciate it adds a maintenance burden to occasionally increase MSRV when a new feature is used, but I'd like to know if there are other downsides I'm missing.

[reitermarkus]

Now we have everything working on 1.32.0 except for:

I don't think the MSRV should apply to specific targets, it should only pertain to the compilation of the cross binary.

The current WG policy means it shouldn't be restrictive to have the MSRV

I think if that remains the case, it's fine to add an MSRV for documentation purposes.

[adamgreig]

I don't think the MSRV should apply to specific targets, it should only pertain to the compilation of the cross binary.

That makes sense, though it might still be useful for users to know what the MSRV is for the target(s) they're interested in. In any event we need to pick a version of Rust for each target; why not its MSRV? There's no reason to expect them to increase per-target now and the majority (all but 3) are 1.32. Otherwise we'll have to add a separate build step to build and test cross on the MSRV in addition to testing each target.

I could also imagine updating the three standouts to use 'stable' instead of specific versions if that seems better?

[reitermarkus]

if that seems better

I think it's fine as is.

[adamgreig]

Are there any other changes you'd like me to make or are we OK to merge this?

[reitermarkus]

Ready to merge.

[adamgreig]

bors r=reitermarkus

[bors]

Build failed:

• rust-embedded.cross

[adamgreig]

bors retry

[reitermarkus]

@adamgreig, some Docker images don't build anymore.

[reitermarkus]

bors r-

[bors]

Canceled.

[reitermarkus]

bors r+

[bors]

Build failed:

• rust-embedded.cross

[reitermarkus]

Seems like updating the dependencies broke the MSRV. Maybe we should just switch to 1.42.0 for all targets for simplicity's sake?

[adamgreig]

Sounds good, let's try that.

[reitermarkus]

bors r+

[bors]

Build succeeded:

• shellcheck
• rust-embedded.cross