Yanking

Yanking withdraws a published version from new dependency resolution while leaving it available to builds that already depend on it. It is the way to retire a release that turned out to be broken, insecure, or published by mistake.

What yanking does and does not do

Yanking doesYanking does not
Stop resolvers choosing the version for a new dependencyDelete the release or its files
Mark the version on the package pageBreak builds that already resolved to it
Take effect immediatelyRemove the version from the index

A yanked version stays downloadable, and the registry keeps serving its metadata and archive. That is deliberate: a lockfile or a CI pipeline pinned to it keeps working instead of failing the moment you withdraw the release. Yanked versions stay in the resolver index for the same reason — an existing build must still be able to identify what it pinned.

Yanking is not deletion and not a security control. The bytes remain public. If you published a credential, treat it as compromised and rotate it — yanking does not take it back.

Yanking a version

Open the package from your dashboard and yank the version there. You need owner or maintainer membership of the package's namespace, and — for the API — a token with the yank scope.

Unyanking restores the version to normal resolution. Both directions are idempotent: yanking an already-yanked version changes nothing and is not recorded twice.

There is no rux yank command yet. Yanking is done from the registry, or through the PATCH /v1/packages/{namespace}/{package}/{version} API with a yank-scoped token.

When to yank

Yank when a release actively harms the people who install it — a security problem, corrupted contents, a build that cannot possibly work, or an accidental publish.

Do not yank simply because a newer version exists. Ordinary supersession is what version requirements are for, and yanking healthy releases makes a package's history harder to depend on.

After yanking

Publish a fixed version. Because published versions are immutable, the fix is always a new release rather than a correction of the old one — usually a patch bump, or a minor bump if the fix changed the API.

Say what happened in your changelog and, for anything security-related, in the repository's advisories. A yank marks a version in the registry; it does not explain itself to the people who were using it.