crate home MSRV bumped in "compatible version"

[tisonkun]

Problem

error: rustc 1.80.0 is not supported by the following package:
  home@0.5.11 requires rustc 1.81

I have this dependency in cargo.toml:

home = "0.5.9"

Such breaking changes deserve 0.6.0.

Steps

Possible Solution(s)

yank 0.5.11 and release 0.6.0

Notes

No response

Version

[tisonkun]

cc @ehuss

[epage]

MSRV bumps are generally recognized as minor, not major changes, see https://doc.rust-lang.org/nightly/cargo/reference/semver.html#env-new-rust

[epage]

We previously discussed this in #13270. Per that discussion, I'm closing this.

[tisonkun]

MSRV bumps are generally recognized as minor, not major changes, see https://doc.rust-lang.org/nightly/cargo/reference/semver.html#env-new-rust

This is reasonable, while I'd ask a bit details on cargo's mechanism.

When I specify "foo = 1.2", will it gets auto resolved to 1.3.x? That is, when I specify "home = 0.5.9", it could be resolved to "home = 0.5.11". But if we specify "foo = 1.2", it would only resolves to 1.2.x?

If so, then "minor changes" means different things in these two situations.

[tisonkun]

That said, you can bump MSRV when bump 1.2 to 1.3, and build won't break with the most common dependency string. But from 0.5.9 to 0.5.11 does.

[tisonkun]

I see https://doc.rust-lang.org/nightly/cargo/reference/resolver.html#semver-compatibility

bitflags = "1.1"  # meaning `>=1.1.0,<2.0.0`

Then I'm fine with Rust's definition now .. let me see how to get used to it.

[epage]

foo = "1.2" means foo = ">=1.2.0,<2.0.0".

Build environment changes are not usually included in semver in Rust. If not, Rust itself would be on v20 or so with glibc, AndroidNDK, Linux Kernel, etc changes. Foundational crates like serde could never change their MSRV. Builds would be slower due to the duplication of dependencies. Users with higher MSRV can be stuck on old, buggy, less featureful versions of their transitive deps because one dep has a lower MSRV.

In 1.84 we'll have an opt-in MSRV-aware resolver. You can have it generate your lockfile and than use whatever version of Cargo you want.

[tisonkun]

In 1.84 we'll have an opt-in MSRV-aware resolver. You can have it generate your lockfile and than use whatever version of Cargo you want.

Cool! Is there a tracking issue I can watch on?

[weihanglo]

• MSRV-dependent dependency version resolution #9930
• https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#msrv-aware-resolver

[weihanglo]

This was stabilized in 1.83 in #14639.

Hum… the version here seems wrong, @epage ?

[epage]

Missed that one

[Ari-suhyeon]

The sudden version restriction is causing problems with my builds too.
The problem is that it's not easy to find which crate has which dependencies...
Debug works fine, release doesn't.
Does anyone know how to fix it?

[weihanglo]

The problem is that it's not easy to find which crate has which dependencies...

cargo tree -i home could help.
See https://doc.rust-lang.org/nightly/cargo/reference/features.html#inspecting-resolved-features.

Does anyone know how to fix it?

cargo update home --precise 0.5.9. See also harryfei/which-rs#103 (comment)

[Ari-suhyeon]

I don't use the home crate directly.
Of course I have used the cargo tree -i home command, but it only specifies home v0.5.9.
I use polars and kube-rs, and those crates also specify v0.5.9.
I am building docker, and the image uses FROM rust:1.78.0-slim.

[Ari-suhyeon]

I've identified the cause.
(The dependency was created because kube-client and polars are using home crate)
When I do a Docker build, the Cargo.lock file doesn't exist, so you create it and build it.
In the existing Cargo.lock file on my local PC, the home version was specified as '0.5.9', so it worked fine, but when I built without the lock file, it was changed to '0.5.11' and the lock file was created.
It seems that 0.5.9 and 0.5.11 are compatible according to SemVer compatibility, so it changes to 0.5.11.
https://doc.rust-lang.org/cargo/reference/resolver.html