# What happened to dependency releases

When a bot opens "bump X from 4.2 to 4.3", the question is whether the update
will hold up after you merge it. This table shows what actually happened to
every stable release of the 200 most-updated npm, PyPI and crates.io packages
over the last 12 months: which ones the maintainers pulled, and which ones
needed a fix within days.

These are outcomes, not predictions. They are the history Rework Risk learns
from for dependency-bump pull requests.

| column | what happened |
|---|---|
| releases_12m | stable releases published in the last 12 months (ranking key) |
| pulled | releases the maintainers yanked (PyPI, crates.io) or deprecated with a reason (npm) |
| pulled_security | pulled releases whose stated reason mentions a vulnerability or compromise |
| fixed_within_72h | releases replaced by a patch on the same version line within 72 hours, and faster than the package normally releases |
| pulled_or_fixed | pulled or fixed within 72 hours |
| share_pulled_or_fixed | pulled_or_fixed as a share of releases_12m |
| removed_npm | npm releases that were unpublished; the registry does not record why |
| median_days_between_releases | the package's normal release cadence |
| recent_pulled_or_fixed | up to five most recent such releases |
| page_path | the package's page on hokus.ai |

**Snapshot, 2026-10-26.** 9,343 releases across 200 packages. 894 (9.6%) were
pulled or fixed within 72 hours, and 159 of the 200 packages had at least one.
Of the 71 pulled releases, 22 gave a security reason.

**What this table does not show.** It records what maintainers did after a
release. It does not detect compromised or malicious releases; those are often
removed from the registry entirely and appear here at most as unexplained
removals. For security, use a dedicated supply-chain scanner.

**A practical setting.** A release cooldown of 3 days (Dependabot `cooldown`,
Renovate `minimumReleaseAge`) would have skipped every release in this table
that was fixed within 72 hours.

**Coming next.** Reverts and pins of these updates in public repositories
(`add_github_reverts.py`, needs a GitHub token).

**See this for your own code.** Rework Risk finds the merged pull requests in
your repo that later needed corrective work, dependency bumps included. [Get a rework backtest on your repo](https://hokus.ai/contact?topic=rework-risk).

Rebuild from the repository root: `python3 scripts/dependencies/build_table.py 200 packages/web/public/data/dependencies/dependency_release_outcomes_top200.csv`

## Reading this snapshot

The candidate pool is curated in `seeds.py`, then ranked by stable release count; it is not a ranking of the entire registries. “Fixed” is a timing proxy: a higher patch on the same major.minor line within both 72 hours and one quarter of the normal release interval. It does not prove that the earlier release was defective. Simultaneous release timestamps count once when computing cadence. Pulled and fixed counts overlap; `pulled_or_fixed` is their union. Shares are omitted below six releases. Reasons are package-level examples truncated to 90 characters, not per-version annotations.

Snapshot date: 2026-10-26. Window: 2025-10-26 through 2026-10-26. All figures are historical, not live registry queries.

## Refresh

From the repository root, run `python3 scripts/dependencies/build_table.py 200 packages/web/public/data/dependencies/dependency_release_outcomes_top200.csv`. Review registry errors and the diff, update SNAPSHOT_DATE and temporalCoverage in the site source and this README, then rebuild. The Python code uses only the standard library. The optional GitHub enrichment is not included in this experiment.