Build out tooling to warn if dependencies in Cargo.toml (or transitive dependencies in Cargo.lock) need to be bumped

[sunshowers]

Cargo uses a version strategy that can be described as "maximal": by default, Cargo picks the highest version that satisfies the provided constraints.

I believe that this is generally the right version selection strategy -- however, it comes with tradeoffs. One of them is that it's possible that Cargo.toml specifies versions that are too old to use but that resolve correctly in practice.

For example, let's say that a package pkg has a dependency foo with an API that was introduced in version 0.2.1. It is possible to get away with specifying:

[dependencies]
foo = "0.2.0"

since Cargo will resolve foo to the highest version in the 0.2 series, 0.2.1 or higher.

This can be a problem if downstream workspaces use any sort of version upgrade strategy other than a simple cargo update. For example, if pkg is updated without foo being updated, pkg may fail to compile. In the worst case, bugs may silently be introduced.

How can guppy help here? There seem to be two potential ways:

• For people developing pkg, guppy can be used to implement the minimal-versions-for-me-but-not-my-dependencies described in Dependencies resolution with --minimal-versions rust-lang/cargo#5657 (this should be pretty easy, I think, unless I'm missing something). Once evangelized as something folks can integrate into CI tooling, this may help improve the health of the overall ecosystem.
• For downstream workspaces, note that every crate published on crates.io comes with a Cargo.lock file describing a snapshot of version resolution at publishing time. The versions in the Cargo.lock files for each upstream crate can be compared against resolved dependencies.

For more, see:

• Minimal Version Selection by Russ Cox
• The pain that minimal version selection solves by Nick Snyder