Skip to main content
← Back to list
01Issue
FeatureShippedSwamp CLI
Assigneesstack72

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-level yankedAt and removes the extension from search on every channel at once — including beta and rc. 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, --yes

Proposed 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, leaving beta/rc discoverable 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

  1. Publish a stable version and a separate --channel beta version of the same extension.
  2. swamp extension yank @col/ext --reason test (whole extension).
  3. swamp extension search <name> --channel beta → the extension is gone from beta too, not just stable.
  4. swamp extension unyank @col/ext restores all channels; there is no way to have scoped the yank to stable only.
  • #624 (demote / withdraw a version from the stable channel) — same underlying gap, complementary mechanism.
02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 3 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

6/11/2026, 6:52:56 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack726/11/2026, 3:33:22 PM
Editable. Press Enter to edit.

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 yanked

The 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.

stack72 commented 6/11/2026, 6:53:05 PM

Thanks @magistr for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.