minimum supported rust version policy

[clux]

Moving towards stability land (#508), we should probably could do a best effort to maintain builds on the last few stable versions of rust. (Originally discussed briefly in #665).

Problems:

• need to restrict dependency updates to upstream policies of their MSRV (which is hard with our dependency tree, but presumably it is automated if people set the rust-version)
• need CI to validate that our MSRV is building on that version
• people suggest a 6 month policy, but it's undoubtedly going to put a strain on maintainers

We just merged in edition 2021 so there's limits to how much we can do (and the 2021 release is incidentally the release that supports rust-version key. For now we could follow this general plan:

• set rust-version to 1.56 in all Cargo.tomls (7a265b9)
• add badge below - add msrv badge + script to generate it #680
• add CI to run against 1.56 (with a sanity check that the rust version matches what we set in Cargo.tomls) - Msrv check on CI for #668 #687
• run that ci job daily pre-merge - Msrv check on CI for #668 #687

and then maybe in the futere (depending on need, and what type of problems we run into):

• speculatively commit to 3 months initially (that's 2 stable rust releases back)
• write a speculative policy document somewhere (e.g. something like wg/msrv)

but that will be one for a later issue - for now; our policy is ad-hoc; but documented in the readme and cargo metadata.

[clux]

edited a bit because not sure we should do this stuff yet. waiting for some more feedback.
have added the rust-version key at least though. that seems like good practice.

[kazk]

I don't know what's best for kube yet (trade-offs), but adding a specific version to CI is a step forward (MSRV discussion in api-guidelines: rust-lang/api-guidelines#123 (comment)). The new rust-version field resolves the pain of finding MSRV of dependencies discussed there, and I'm sure we'll have tools to help in the future as more crates set this field.

The oldest rust-version kube can set is the newest rust-version from the dependencies. Likewise, kube's rust-version may determine the oldest for the dependents. So, in general, lower level crates should have a longer MSRV policy. 3 months for kube sounds decent to me, and that can be a best effort basis before v1 (at least consider if bumping rust-version is worth the gain).

Personally, I wouldn't mind kube having rust-version set to the latest stable at the time of each release, but that's because I don't have any use not under my control. Maintainers of popular tools/libraries will appreciate this.

• add CI to run against 1.56 (with a sanity check that the rust version matches what we set in Cargo.tomls
• run that ci job daily

Can't we add a new job msrv that checks if it compiles with rust-version? Few jobs run in parallel, so CI shouldn't take that much additional time. Not sure if we need to run all the tests for MSRV check.

[lfrancke]

FWIW: It'd be nice to have the current MSRV in the readme. Yes, I know, I can read the policy and I can look at a cargo.toml but if I come in through Github that's the first thing I see.

I'm also fine with 3 months and in general everything you and @kazk said sounds fine to me. Thank you!

[kazk]

We can add a badge.

#dea584 is the color GitHub uses for Rust.

[clux]

That badge is great. I wrote a small script to generate that from cargo-msrv.