0.20 release implicitly raised MSRV of rust-ini to 1.71 (July 2023)

[polarathene]

While the Github README and releases is still 0.19, you recently released 0.20 with a version bump on a dependency. This raises rust-ini to MSRV of 1.71 (July 2023), preventing any rust toolchain earlier from building the rust-ini crate due to use of unstable features.

• Upstream bug report: Document Rust MSRV of 1.71 requirement for release 0.7.1 sgodwincs/ordered-multimap-rs#26
• Caught by CI in downstream crate config-rs: Update rust-ini requirement from 0.19 to 0.20 rust-cli/config-rs#494

---

Probably unintentional since neither ordered-multimap or rust-ini mention the impact of this.

• This was due to ordered-multimap release of 0.7.1 paired with Oct 18th change to rust-ini bumping the Cargo.toml dependency from 0.6 to 0.7.
• ordered-multimap released 0.7.0 on Aug 24th, and 0.7.1 on Oct 25th, so rust-ini wouldn't have caught that at the time.

[zonyitoo]

What's the recommended solution?

[polarathene]

What's the recommended solution?

TL;DR:

• Wait a little bit longer and then maybe consider adding rust-version to Cargo.toml going forward.
• Alternatively, as this is apparently a common practice to bump MSRV in point releases, downstream projects delay upgrading rust-ini until they can raise their MSRV high enough.

---

This should be resolved soon upstream if the crate author yanks earlier versions and publishes their crate with rust-version: sgodwincs/ordered-multimap-rs#26 (comment)

That would then support Rust from 1.64.0 and the update for nightly + lint (MSRV bump to 1.71.1) would then be published as another release ideally with rust-version bump, where cargo would resolve 0.7 to a published release that is compatible with rust-version of the active toolchain 👍

---

rust-ini might also want to consider adding rust-version to Cargo.toml?:

• Presently while on 0.x.y releases, the semver range is mostly only relevant to patch release versions AFAIK? (unless using rust-ini = "*"?)
• Still there might be value in also maintaining rust-version for rust-ini?
• rust-version = "1.64.0" would be accurate for ordered-multimap = "0.7" if it publishes a release with that rust-version declared as well. Another release of the 0.7.x crate could then bump to rust-version = "1.71.1" (which would not require rust-ini to do so), rust-version = "1.64.0" would then still be valid for the MSRV to build rust-ini 0.20.0 then 👍

See the linked ordered-multimap issue for an example of rust-ini 0.18.0 where the ordered-multimap = "0.4" semver range correctly resolves to ordered-multimap 0.4.0 with cargo +1.56.1 check (despite newer point releases in the semver range), as the hashbrown dependency maintained rust-version bumps that benefit its downstream dependents (parent crates) lacking any rust-version info.

[polarathene]

Update, I'm mistaken about cargo supporting rust-version when resolving. That only seems relevant to the nightly -Z msrv-policy resolver feature.

sgodwincs/ordered-multimap-rs#26 (comment)