What a yank does not do
It does not remove an artifact that is already installed, and it does not fix a running box. It changes what future resolves pick. Existing deployments need their own migration.
Yanking a release that must not be used
Sometimes a release has to be withdrawn: it has a bug that cannot be fixed without breaking the contract. Semantic versioning has a word for that, yanked, meaning 'this version exists in history but must not be resolved'. The point is to make the withdrawal visible, not to delete it.
What you will see
latest, if present, must not point at the yanked build. Repoint it to the resolved version.
About 1 min of reading
Try It
Yank a version and watch the resolver skip it
1
Tag the bad release
docker build -t app:v1.4.3-bad .
Before you run it, say out loud what it will print. Then open the answer.
What it prints
The artifact exists so history is preserved; do not delete it.
2
Record the yank
printf 'yanked: v1.4.3, reason: pagination skips last item\n' >> YANKS.txt
Before you run it, say out loud what it will print. Then open the answer.
What it prints
A record file that a resolver can read and a human can grep.
3
Resolve with the yank in place
python -c "from packaging.version import Version as V; c=[V('1.4.2'),V('1.4.4')]; print(max(x for x in c if V('1.4.0')<=x
Before you run it, say out loud what it will print. Then open the answer.
What it prints
1.4.4. The yanked 1.4.3 is not in the candidate list, so the range resolves around it.
4
Check no pointer moved back
docker images --format '{{.Tag}}' | grep -c 'latest'
Before you run it, say out loud what it will print. Then open the answer.
What it prints
latest, if present, must not point at the yanked build. Repoint it to the resolved version.
Never yank the version every existing deployment is running on without a migration path. The yank changes future resolves, not running boxes.
Data Flow
Bad release to skipped resolve
1
Mark 1.4.3 yanked with a reason
↓
2
Consumer resolves >=1.4.0,<2.0.0
↓
3
Resolver skips the yanked entry
↓
4
Log names the skipped version and the reason
Why this works
When you have a choice
Yanking versus a hotfix release
If you can ship a version that works, ship it and yank the bad one. Yank alone only when there is no working version to point at.
Examples
Yank, do not delete
Deleting a release from a registry leaves consumers with a version they cannot re-fetch and a build that will not resolve. Marking it yanked keeps the history and fails the resolve with a clear message.
The floor skips it
A range >=1.4.0,<2.0.0 with 1.4.3 yanked resolves to the highest non-yanked version. Consumers get a working version and a log line saying one was skipped.
Record why
The yank carries a reason string. That string is what a reader needs six months later to know whether the fix landed in 1.4.4 or whether they must change code.
Words this lesson uses
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.
← Dependency ranges in a lock file
Previous Lesson
Dependency ranges in a lock file