Home crate: Updated minimum Rust version for a patch release??

[danielgerlag]

home 0.5.11 required Rust 1.81
home 0.5.12 requires Rust 1.88

Many projects that rely on the minor version (0.5.*) have their CI builds broken as many CI build tools only currently support Rust 1.86.
It is fine to update the minimum required Rust version, but this should have been version 0.6.0, since this is a breaking change for build pipelines.

[epage]

Note that home uses 0.x.y which only gives a "breaking" number and a combined "minor" + "patch.

The general ecosystem consensus on this is that raising an MSRV is not a breaking change (for a lot of reasons). We have some comments on this at https://doc.rust-lang.org/cargo/reference/semver.html#env-new-rust.

Note that we just had #16197 opened for this specific version bump which is closed in favor of #14944 which is closed because of the decision of the cargo team recorded in #13270.

Note that it may be a good idea to commit your lockfile which would cause your CI to not break in situations like this. We also have support an MSRV-aware resolver that can be opted-into via config without raising your MSRV, only requiring dependency updates to be done with a new enough version.

[quasi-coherent]

The general ecosystem consensus on this is that raising an MSRV is not a breaking change (for a lot of reasons). We have some comments on this at https://doc.rust-lang.org/cargo/reference/semver.html#env-new-rust.

From the page you link:

Introducing the use of new features in a new release of Rust can break projects that are using older versions of Rust. This
also includes using new features in a new release of Cargo, and requiring the use of a nightly-only feature in a crate that previously worked on stable.

It is generally recommended to treat this as a minor change, rather than as a major change, for various reasons.

Emphasis mine.

[epage]

To double check, are you intended to raise the visibility of the section I was referring to by quoting and emphasizing it here or was there something else you were looking to call out?

[quasi-coherent]

To double check, are you intended to raise the visibility of the section I was referring to by quoting and emphasizing it here or was there something else you were looking to call out?

I just picked this one out of all the issues about this that you're closing, but I'm pointing out that the document you linked to suggests that a change such as the one in question deserves a minor version increase, not a patch. So 0.5.11 -> 0.6.0, not 0.5.11 -> 0.5.12.

Edit: And I just remembered the weird Rust semver idiosyncrasies for zero versions... So 0.5.x -> 0.6.x is a major release, I guess is how you're saying that it's OK?

[epage]

Edit: And I just remembered the weird Rust semver idiosyncrasies for zero versions... So 0.5.x -> 0.6.x is a major release, I guess is how you're saying that it's OK?

Yes, as called out earlier in this thread

Note that home uses 0.x.y which only gives a "breaking" number and a combined "minor" + "patch".

[weihanglo]

Also:

This guide uses the terms “major” and “minor” assuming this relates to a “1.0.0” release or later. Initial development releases starting with “0.y.z” can treat changes in “y” as a major release, and “z” as a minor release. “0.0.z” releases are always major changes. This is because Cargo uses the convention that only changes in the left-most non-zero component are considered incompatible.

The major and minor in this doc I think is more like "major SemVer bump" (which si also mentioned at the very beginning of the doc).

[quasi-coherent]

Edit: And I just remembered the weird Rust semver idiosyncrasies for zero versions... So 0.5.x -> 0.6.x is a major release, I guess is how you're saying that it's OK?

Yes, as called out earlier in this thread

Note that home uses 0.x.y which only gives a "breaking" number and a combined "minor" + "patch".

Thank you so much for the clarification!

[danielgerlag]

So basically, every release should be considered breaking?
and there is no mechanism to release a non-breaking change?
Sounds practical?
Next question, why is "home" still a "0.x.x"?

[epage]

"Breaking", in terms of SemVer, is focused on APIs and is a matter of what else you decide to include beyond that. The Rust community generally does not consider build system requirements as a "breaking change". If we had, Rust itself would be making breaking changes to require new kernels, libcs, etc.

Setting aside those semantics, your build is breaking. Earlier, I listed ways to not have that happen.

As for 0ver, that wouldn't make a difference to this situation. Changing 1.x.0 instead of 0.5.x wouldn't make a difference. As for any other benefits to you for being 1.x.y, keep in mind that the docs explicitly state that home is an internal crate to Cargo and not intended for general use. The standard library has a home_dir functiun that was recently un-deprecated. If your MSRV is new enough or you don't use Windows, I'd recommend using that.

[danielgerlag]

So answers to my questions are

1. yes
2. yes
3. no?
4. it's deprecated?

Unfortunately, I am not using "home" directly, I am using "kube-client" which uses "home", so I do not have the luxury of not using it.