Giters

zonyitoo / rust-ini

INI file parser in Rust

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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

polarathene opened this issue · comments

commented

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.

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.
commented

What's the recommended solution?

commented

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.

commented

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)