v0.8.4 increased MSRV to 1.61

[fujiapple852]

Version 0.8.4 introduced the zerocopy 0.7.x dependancy which increased the MSRV to 1.61 (19 May 2022).

Cargo treats 0.8.4 as semver compatible with 0.8.3 and so this causes failures for project using ahash which have a MSRV of 1.60 or lower:

error: package `zerocopy v0.7.12` cannot be built because it requires rustc 1.61.0 or newer, while the currently active rustc version is 1.60.0

I don't know what the project semver and MSRV policy is and therefore I don't know whether you consider this an issue or not.

As 0.8.3 has been yanked it seems the only option are to go back to 0.7.x or bump the MSRV of crates using ahash.

[polarathene]

For reference this isn't the first time this has happened with ahash.

Bumping MSRV is sometimes unintentional, but it's also not uncommon to see happen in point releases, often due to to a crates dependencies either being updated, or the semver range supporting future releases that introduce the MSRV bump.

Adopting rust-version in Cargo.toml can be helpful and used with cargo features like the nightly -Z msrv-policy option to better resolve compatible packages for your projects MSRV.

However it's only a guide, take hashbrown 0.14 with its rust-version = "1.63.0", by default it needs to be 1.64.0 to build successfully due to a dependency, but otherwise Rust 1.63.0 will be successful if pinning to a lower version of the allocator-api2 dependency (which they support via the Cargo.toml minimum semver range, thus you can update the Cargo.lock for just that version, or add it to your own Cargo.toml).

---

ahash 0.7.6 raised MSRV to 1.60.0 implicitly, when IIRC this would previously build on Rust 1.56.0 for hashbrown 0.11.2 (Mar 2021). Due to the yanked releases, an earlier release isn't usable for those published releases of hashbrown with a ahash = "0.7" semver, while the ahash 0.7.6 release came after them (Sep 2021).

For a crate like ordered-multimap = "0.4", it would fail to resolve the hashbrown version bumps (as it could not understand the new Cargo.toml support introduced from Rust 1.60.0 on older rust toolchains that ahash 0.7.6 had introduced). This would result in resolving the 0.4 semver to ordered-multimap 0.4.0 instead of 0.4.3, using ahash 0.4.8.

---

When MSRV bumps don't result in that rollback resolver behaviour due to the toolchain considering the Cargo.toml invalid, you'd get a failure like reported above for zerocopy.

If the yanked releases situation did not happen and rust-version was adopted in Cargo.toml, at least the semver issue could be use a workaround via Cargo.lock with cargo +nightly update -Z msrv-policy which would take a projects own rust-version in their Cargo.lock and resolves compatible crate dependencies, rolling back releases in the semver until a compatible rust-version is found, or the absence of rust-version (which may not be compatible).

---

When you have rust-version declared for your crate, it's visible on crates.io versions tab too:

As you can see, it did have an MSRV of 1.61.0, but very recently dropped that down to 1.60.0 👍 (no longer an issue with ahash)

[tkaitchuck]

Please confirm if this will fix the problem: #181

[fujiapple852]

@tkaitchuck lgtm

[polarathene]

Please confirm if this will fix the problem: #181

Since zerocopy does declare rust-version, it would be the same experience for a user of ahash:

• If they tried to install ahash = "0.8" semver dependencies are resolved and a version of ahash with the zerocopy dependency is installed.
• zerocopy already declared rust-version = "1.61.0", so this fails on earlier toolchains. ahash with it's own rust-version = "1.60.0" does not prevent that AFAIK, that just identifies which release of ahash is considered compatible with that Rust toolchain release, but does not guarantee it if dependencies exceed it.
• zerocopy failed as when the issue was reported, 1.61.0 was the MSRV supported for all releases in the 0.7 semver that ahash accepted. A user could use -Z msrv-policy and it would fail just the same.
• Since this issue was reported, zerocopy has pushed out a new release with a lowered rust-version within the 0.7 semver, so this will pass fine regardless.
• If zerocopy raised it again in 0.7x, this is when -Z msrv-policy would resolve down to the earlier 1.60.0 compatible release for any toolchain between 1.60.0 and below the new rust-version MSRV.

---

You should still adopt rust-version despite that.

As mentioned, you've introduced changes in the past that raised the MSRV implicitly (such as with 0.7.6 requiring Rust 1.60.0).

• If you adopt rust-version and update it when changes to ahash raise MSRV then users can leverage -Z msrv-policy to resolve the semver range to a release that is compatible with their rust toolchain.
• At the time of a release it's valid, but dependencies may break that with their own MSRV bumps in the same valid semver range.
  • Usually rust-version will prevent that being a problem, but it is not always reliable (see hashbrown 0.14.2 which declares rust-version = "1.63.0", it does not support that by default unless pinning a dependency version (allocator-api2 0.2.9) or opt-out of a feature, that dependency does not use rust-version itself hence the problem)

rust-version will be a guideline and broader adoption will at least minimize the issue of older MSRV requirements, remaining burden falls on the downstream beyond that.

[fujiapple852]

@tkaitchuck I see that the latest patch release of aHash (0.8.8) bumps the MSRV 1.72. Is it safe to say that the policy of this crate is that you do not consider a MSRV bump to be a breaking change? This would be useful to document so downstream crates can act accordingly (i.e. pin the version)

[polarathene]

Is it safe to say that the policy of this crate is that you do not consider a MSRV bump to be a breaking change?

You can't really consider it a breaking change. A crate can release and have a dependency update afterwards that is within the semver range which introduces a change that requires a higher MSRV to support.

If that dependency used rust-version in Cargo.toml you can prevent that issue implicitly raising for dependents.

Just look at the problems identified above in my earlier comments for further context (or this comment which explains why it's not a breaking change).