Hacker News new | ask | show | jobs
by ComputerGuru 665 days ago
I’m confused. If you rely on a feature introduced in X.y.z why would you specify X.y.0 to begin with (and not just X.y.z)?

In practice, usual rust projects that have not put a ton of work into their dependencies encode X.y.z in Cargo.toml matching the current release at the time they developed the system. So you get at worst an unnecessarily higher version requirement but never a lower one.

Moreover, rust semver would normally imply that new features should only be introduced in X.y releases, so this doesn’t really happen in practice!
2 comments
gmueckl 665 days ago
It's easy to accidentally ship a minimum version requirement that is out of date when you also consistently use lock files pinned to newer versions. The code may silently depend on something introduced in a newer version pulled in by the lock file.
link
sanxiyn 665 days ago
You can have a CI builder using direct-minimal-versions to check this.
link
ComputerGuru 664 days ago
Point releases are often bugfix releases, i.e. not api changes but runtime changes. CI won’t help without very specific accompanying tests.
link
stouset 664 days ago
I have literally never run into this being a problem in practice. If someone downstream ever did notice, they can just specify a higher minimum version constraint.
link
stouset 664 days ago
Just have CI build with the minimum and the maximum.
link
joshka 664 days ago
My point was not about "x.y.0" (I mispoke), but "x.y" (or "0.x") that causes this problem.

Take a look at any random crates's cargo config, and you'll regularly see dependencies specified as "1" or "0.3" instead of "1.0.119" or "0.3.39". If another crate depends on this crate, and has a more precise version needed (say "=1.0.100" (perhaps due to a bug introduced in "1.0.101", but the included library relies on features introduced in some version after "1.0.100", then your library won't compile. Stating your dependency on "1" instead of "1.0.119" is what caused this problem.

This is not hypothetical - I've run into this quite a few times with crates that over-specify their dependencies interacting with crates that under-specify theirs.

Yes, the solution to this is pretty simple - check minimal versions in CI. That's something I do for most of my stuff, but it's not universal.

link