¶“Minimal Version Selection Revisited”
2024-12-26
matklad points out an interesting feature of Minimal Version Selection, the dependency resolution strategy used by Go:
Minimal Version Selection Revisited
MVS is notably the “dual” of the more common maximal version selection, which is used by Rust and most other language package managers. Maximal version selection is open, in the sense that the set of versions that will be used to build a particular application can change over time, as new versions of dependencies are released. (This is why languages that use maximal version selection will typically have some kind of lockfile mechanism, to “lock” dependency resolution to the result that you got at a particular moment in time.)
With MVS, newly released versions aren't selected until someone actively updates their manifest to ask for the newer version. (In Go, this is typically done via the go get -u command.) This has an interesting corollary. As matklad puts it:
That is, any version in your dependency graph is additionally vetted manually by someone who is not the original library developer.
And in turn, that means that you don't need a central registry of published package versions; you can get that information instead in an emergent fashion from the manifests of your (transitive) dependencies. (Throw in a Merkle-style hash checksum for integrity checking and a caching mechanism for efficiency.)