Fix minimal versions dependencies

[faern]

The CI job I added in this PR is something I try to run on all my crates as well. It's something that catch if the crate (or a transitive dependency) has under-specified a dependency.

cargo +nightly update -Z minimal-versions downgrades the entire dependency tree to the lowest allowed versions according to all the dependency semver specs in their Cargo.toml files.

It's very common to just add foo = "0.3" manually and then write code and run. Not realizing cargo automatically pulls in the latest version at the time. That might be foo 0.3.8 and you might unknowingly depend on features introduced in foo 0.3.4. A CI check like this makes sure you don't under-specify version requirements like that.

I found this because I depend on trycmd and this became an error with filetime. See this CI run: https://github.com/mullvad/unicop/actions/runs/9709586296/job/26798567031?pr=2. You depend on filetime::set_file_mtime, but that was introduced in filetime 0.2.6. However, I had to bump the version even further, because filetime did not build with minimal versions until 0.2.8.

[coveralls]

Pull Request Test Coverage Report for Build 9714439987

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 51.654%

---

Totals
Change from base Build 9501692150:	0.0%
Covered Lines:	1390
Relevant Lines:	2691

---

💛 - Coveralls

[coveralls]

Pull Request Test Coverage Report for Build 9721314969

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 51.654%

---

Totals
Change from base Build 9501692150:	0.0%
Covered Lines:	1390
Relevant Lines:	2691

---

💛 - Coveralls

[epage]

Looks like a dep has a minimal-versions problem

[faern]

Looks like a dep has a minimal-versions problem

Ok. Crap. We'll see when I have time to submit the same to them then.

[faern]

Fixed. There were two more crates in this dependency tree which did not specify their dependencies correctly at their oldest versions allowed by this crate. But all of them had fixed the issue in newer versions. So just bumping the minimum version here in this repository fixes the issue.

Arguably those crates should also have a minimal-versions CI job. But they currently have no issue with this, and I don't currently have the time to submit that upstream :)

[coveralls]

Pull Request Test Coverage Report for Build 9756713128

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 51.654%

---

Totals
Change from base Build 9501692150:	0.0%
Covered Lines:	1390
Relevant Lines:	2691

---

💛 - Coveralls

[epage]

btw why did this matter and why was this started off with --all-targets?

In theory, minimal versions is only relevant for dependents, and not yourself. We could lower the ecosystem burden of adopting this by leaving off the --all-targets flag and only checking default targets.

[faern]

--all-targets was put there to catch invalidly specified dependencies used in examples and tests etc as well as the main library/binary code.

How much of a burden do you regard this CI check to be to adopt? I don't think it's very hard at all to keep the dependencies well specified, once this check is in place. And when adopting this CI job it's very easy to fix any existing issues. The only time it's a real problem is if a dependency you depend on have made the same error. But then it's only luck if that dependency happens to be a dev dependency instead of a prod dependency and you ignore checking dev dependencies by leaving out --all-targets.

I personally find it does not simplify things a lot to remove --all-targets but instead it makes the CI checked miss what it was supposed to uphold.

[epage]

From my understanding, the primary value add of verifying version requirements is for people who depend on you. I'm not seeing the value for tests and examples.

However, I'm much more free with my dev-dependencies than other dependencies and by excluding dev-dependencies, it reduces the number of people I have to bug or workaround to make this work as I adopt it across all of my projects.

[faern]

I see your point. If you write a library, keeping everything neat and tidy for your own project's sake vs keeping it correct for your consumers are two different things. However it's still objectively wrong to say [dev-dependency] foo = "0.2" if your tests use features in foo 0.2.3. However, I can agree that this error is not likely to cause much trouble in practice. And as you say, if/while the ecosystem often commit these crimes, it's going to inflict a bit more pain on you downstream, the more dependencies you strictly check for this correctness property.

On the other hand, checking stricter and actively pushing these CI jobs upstream (like I just did) will spread it faster 🤷

I don't have a very strong opinion about dev-dependencies. But I do think we should push for this being a more standard CI check in general. Would be great if it could be stabilized, so nightly is not required.

[faern]

Would it be possible to get a release of trycmd? Since the latest version on crates.io still depend on snapbox ^0.6.0, which has the minimal-versions issue, my minimal-versions CI fail. Thank you 😊

[epage]

Released

[smoelius]

FWIW, I found this discussion very enlightening. Thank you, @faern! Thank you, @epage!