Cleaner README, remove MSRV shields

[dhardy]

• Inherit several package fields from the workspace. Exceptions: licence (pedantic), authors (pedantic and not always constant).
• Clean up the README a bit. I don't think we need to discuss the MSRV there; it also wasn't accurate since rust-version prevents older rust versions from attempting to compile the code-base.
• Remove MSRV shields from READMEs: this is no longer common practice for crates, nor particularly useful.
• MSRV version number from the CI script (hacky, copying some code from the Bevy CI).

This reduces the MSRV to one place: the top Cargo.toml.

[newpavlov]

I don't think it makes sense to share the version field. A minor change in, say, rand will not warrant new releases of other crates.

MSRV of crates also may evolve differently (e.g. adding new SIMD backends to rand_chacha may bump its MSRV), especially considering that in future we will get MSRV-aware resolver and thus will be able to bump MSRV "backward compatibly".

[newpavlov]

On a somewhat relevant note: it may be worth to consider moving rand into its own folder and use virtual manifest for workspace.

[dhardy]

MSRV of crates also may evolve differently

I take the view that if it isn't tested, it doesn't work, and we only have one CI test for MSRV. We've been using a common policy across this repo for a while already.

I suspect rand_core and RNG crates may work with a lower rustc, but don't really care; half our deps now require a higher MSRV anyway (at least if you count dev deps).

[newpavlov]

It's matter of bumping MSRV in future, e.g. why should MSRV bump for rand_distr bump MSRV for rand? Yes, different crate MSRVs would require some CI changes, but it's nothing impossible.

Also, I don't think that this:

edition.workspace = true
rust-version.workspace = true

is cleaner than this:

edition = "2021"
rust-version = "1.61"

Yes, it helps with bumping MSRV/edition, but we do it quite rarely, while user often look into Cargo.toml for information about crate and such indirection only wastes their time.

[dhardy]

It's matter of bumping MSRV in future,

It doesn't prevent that.

Also, I don't think that this: ... is cleaner than this:

No. The only advantage is making those values easier to change.

Bevy have a cleaner set-up, but I couldn't find doc on how it works and .workspace = true was needed in testing...

Either way, this stuff isn't very important.

[vks]

it also wasn't accurate since rust-version prevents older rust versions from attempting to compile the code-base.

I don't think so, older Rust versions will just ignore rust-version and print a warning.

I agree makes sense to have the same MSRV for all crates if that is what we are testing. If the MSRVs diverge, it should be reflected by the CI, and we can still change that later.

[dhardy]

Workspace inheritance was only stabilised in 1.64 so we can't do that yet.

We should probably still link the upgrade guide?

Done.

I don't think so, older Rust versions will just ignore rust-version and print a warning.

No (at least not since versions which support rust-version).

$ cargo +1.60 test
error: package `rand_core v0.9.0-alpha.1 (..)` cannot be built because it requires rustc 1.61 or newer, while the currently active rustc version is 1.60.0