Relationships
#626 Feature: make extension yank channel-scoped (--channel) so it doesn't nuke every channel
Opened by magistr · 6/11/2026· Shipped 6/11/2026
Problem
swamp extension yank is channel-blind, which makes it unusable for managing a single channel without collateral damage. Observed empirically:
- Whole-extension yank (
swamp extension yank @col/ext --reason ..., no version) sets extension-levelyankedAtand removes the extension fromsearchon every channel at once — includingbetaandrc. So yanking because of a bad stable release also makes the extension vanish for beta/rc testers. There is no way to say "withdraw from stable but keep beta available." - Version yank (
yank @col/ext <version>) is the only surgical option, but it targets a single version, not a channel. Yanking the latest stable version usefully rolls the stable pointer back to the previous non-yanked stable version (good — see #624), but a maintainer who wants to pull an extension off stable entirely while keeping a beta track alive has to yank every stable version one by one, and even then the whole-extension yank is the only "remove from discovery" lever and it hits all channels.
yank has no --channel option:
yank: Yank an extension or specific version from the registry.
<extension> [version]
--reason (required)
-y, --yesProposed solution
Add --channel <stable|rc|beta> to swamp extension yank / unyank:
swamp extension yank @col/ext --channel stable --reason ...— withdraw the extension's presence from the stable channel only, leavingbeta/rcdiscoverable and pullable.- Without
--channel, preserve today's behavior (or require the flag to avoid surprising all-channel yanks).
This pairs with the demote/withdraw request in #624: channel-scoped yank is the concrete mechanism for "take it off stable, keep it on beta."
Repro
- Publish a stable version and a separate
--channel betaversion of the same extension. swamp extension yank @col/ext --reason test(whole extension).swamp extension search <name> --channel beta→ the extension is gone from beta too, not just stable.swamp extension unyank @col/extrestores all channels; there is no way to have scoped the yank to stable only.
Related
- #624 (demote / withdraw a version from the stable channel) — same underlying gap, complementary mechanism.
Shipped
Click a lifecycle step above to view its details.
magistr commented 6/11/2026, 1:14:08 PM
Additional finding: whole-extension yank also blocks republishing (HTTP 410)
Tested the obvious recovery path — yank the whole extension, then push a fresh version to a different channel (beta) instead of unyanking. The registry refuses it:
$ swamp extension yank @col/ext --reason ... -y # whole-extension yank
$ swamp extension push @col/ext/manifest.yaml --channel beta --yes
Extension API error (HTTP 410): Extension has been yankedThe local --dry-run builds the archive fine; only the real upload is rejected.
Impact: a whole-extension yank is a hard wall. It (1) hides the extension on every channel, and (2) blocks any new publish — even to a channel that wasn't the reason for the yank. There is no "yank off stable, keep a fresh beta alive" path: the only way to publish again is unyank, which restores all channels at once. This is the same channel-blindness as the original report, on the publish side.
Reinforces the ask: yank/unyank (and the republish gate) should be channel-aware, so a maintainer can withdraw one channel while continuing to ship on another.
Sign in to post a ripple.