Serguey Asael Shinder: A pinned version needs a way to hear that it was withdrawn
Pinning dependencies is one of the few practices nearly everyone agrees on. A lockfile, an exact version, a container image referenced by digest - each one turns "whatever was newest when the build ran" into a fixed input, and a fixed input is what makes a build reproducible and a rollback possible.
The cost is less discussed. A pinned build does not only ignore new releases; it ignores news about the release it already has. When a maintainer withdraws a version - because it has a security hole, because it corrupts data, because it was published by mistake - the projects that pinned it keep installing it, perfectly reproducibly, until a person notices.
Package ecosystems handle withdrawal in ways that are designed not to break pinned builds, which is reasonable and also exactly why nobody hears about it. Yanking a crate or a Python release hides it from new resolution but still serves it to anyone who asks for that exact version. Deprecating an npm version prints a warning at install time, in a CI log nobody reads when the build is green. Container images are the bluntest case: when a maintainer deletes a tag or an image, a pipeline that pulls it fails, but a cluster that already has the image cached keeps running it indefinitely.
So the pin needs a second half: a channel that tells you when the thing you pinned has changed status. Three cheap forms of it, in increasing order of effort:
- Read the advisories you already get. Most hosting platforms already raise alerts when a pinned dependency has a published advisory. The failure is usually not a missing alert but an alert routed to a queue nobody owns. Decide who reads them.
- Treat a withdrawal as a failing check. A scheduled job that resolves your lockfile against the registry and fails when any pinned version is yanked, deprecated or flagged is a few lines of script in most ecosystems. It turns a silent change into a red build on a day you choose.
- Record why each pin exists. A pin with a comment - "held at 6.3 until the sync fix ships" - can be revisited. A pin with no reason becomes permanent by default, and the withdrawal notice for it arrives at a project that no longer remembers choosing it.
None of this undoes the case for pinning. Reproducibility is worth having. But a reproducible build of a withdrawn release is still a withdrawn release, and the pin should be the start of a relationship with that version, not the end of one.