[release-0.13.x] Update MSRV to 1.63.0

[matthiasbeyer]

Foe the next 0.13.x release, we need a newer MSRV, because the log dependency does not build with 1.59.0 anymore.

So we update the MSRV here.

[matthiasbeyer]

I don't like where this is going...

[matthiasbeyer]

UUuuh all green now. @ijackson you're welcome to experiment on another solution. If that does not work out, we can merge this PR instead. But I'll wait for your stuff. And no need to hurry if you cannot get it done tomorrow - I have time! :laughing:

[polarathene]

I don't like where this is going...

There's a cargo command (third-party IIRC) that can be used to identify the MSRV for a project based on its dependencies I think?

You may want to also manage it in the Cargo.toml as one of my PRs mentioned.

[ijackson]

Instead of this MR, how about the approach I took in #492 ?

[polarathene]

FWIW, cargo-msrv could detect the requirement with dev-dependencies too. It supports providing a custom command such as cargo check --tests. This avoids the approach taken in this PR with incremental bumping until the CI is happy.

The MSRV of many crates during my investigation were averaging around 1.63 / 1.64, others with 1.60. Since @ijackson has an MSRV of 1.65, you could probably consider 1.64 going forward.

1.63 is also apparently what the current Debian stable (Bookworm) release is using, which is an MSRV target for some projects, but Debian is rather slow pace, other crates have an MSRV policy that would / has moved on from that. Less of an issue when they adopt rust-version in Cargo.toml.

---

I think Cargo.toml can address the current CI issues with a Cargo.lock.msrv file (seems best practice?) and set a 1.56 rust-version.

Nothing else in config-rs for this branch requires raising the MSRV beyond deps and how they're resolved by default, that doesn't really warrant raising rust-version unless you want to update Cargo.toml in a way that'd require it. MSRV policy is different AFAIK, and some CI will use a higher MSRV for running tests (rust-version can still be verified separately).

TL;DR

• MSRV / rust-version bumping as a response due to implicit dep updates should not be necessary.
• rust-version is more accurate representation of what the project can build with.
  • Explicit changes to Cargo.toml or project code may require raising rust-version.
  • MSRV bumps are not considered a semver breaking change.
  • Especially when it's inherited from dependencies without adjusting Cargo.toml. That would likewise already affect prior releases that have been published since.
  • Treating as a semver breaking change can cause more issues, as would have been the case with log. rust-version better resolves this concern.
  • Bumping it may be valid if generating / resolving a Cargo.lock becomes unwieldy to maintain.
  • I don't really consider it applicable as a constraint to building examples or running tests, aka dev-dependencies, at least when Cargo.lock is committed.

[matthiasbeyer]

0.13.x is now no longer the latest release, so I'll close this unmerged. All patchreleases go to 0.14.x now.