Prefer yanking over deleting. A yanked release stays downloadable for people who pinned that exact version, but installers steer new installs to a good version. Deleting a release breaks anyone who pinned it, and it removes evidence customers need to check whether they are affected.
Definitions
Yanking, as defined for Python package indexes in PEP 592, marks a file so installers should not normally select it. The PEP says installers must ignore a yanked file when the constraints can be met by a non-yanked version. The state is reversible, so clients must cope with a file being yanked, unyanked and yanked again. Deleting removes the file.
Why deleting hurts
The PEP describes a catch-22. If you delete a broken release, users who pinned it can no longer build. If you leave it, new users may pick it up. Yanking solves both. Installers may ignore a yanked file unless it is the only match for an exact pin, or unless a lock file names it, and they should warn when someone installs a yanked file. The yank can carry a reason string that installers may show.
When each applies
| Situation | Action |
|---|---|
| Release has a serious bug, no secret exposed | Yank, publish a fixed version, explain in the notes |
| Release contains a vulnerability | Yank, publish a fixed version, publish an advisory naming affected and fixed versions |
| Release contains a leaked secret | Yank, rotate the secret first, then decide on removal with legal advice |
| Release is malicious or must not be redistributed | Remove it, keep a record, and notify customers directly |
The point is that yank is a signal and removal is a last resort. Not every channel supports yanking. For your own download site, you can mimic it: keep the file, remove it from the "latest" pointer, and put a banner on its page.
Steps for your own download site
- Mark the release as withdrawn on its page with the reason and the replacement.
- Take it out of update manifests so clients stop offering it.
- Leave the file and its hash available, so customers can identify what they run.
- Send the notice to your advisory list.
- Record the dates, so your support team can answer "since when".
Mirrors
The PEP says mirrors must not mirror a yanked file without also mirroring the yank marker. If customers run internal mirrors, tell them to preserve it.
If you want a second look at what you ship, Safeguard can generate and scan an SBOM and run dependency scanning with reachability analysis, and you can try the free scan.
Quick check
Does yanking remove a release from customers who already installed it?
No. It only changes what installers select. Customers need your advisory or notice to know to move off it.
When is deletion justified?
When the release is malicious or cannot lawfully be redistributed. Even then, keep a private record and notify customers.
Sources
Last reviewed: 19 October 2026.
