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

Relationships

#624 Feature: demote / withdraw an extension version from the stable channel

Opened by magistr · 6/11/2026

Problem

Release channels (#608) only move upward. swamp extension promote hard-restricts the target to rc or stable and the source (--from-channel) to beta or rc:

promote: Promote an extension version to a higher release channel (beta→rc, beta→stable, rc→stable)
  --channel       Target channel to promote to: 'rc' or 'stable'   (required)
  --from-channel  Source channel ('beta' or 'rc')                  (optional)

There is no way to move a version down a channel, nor to withdraw a version from stable so the stable pointer falls back to the previous good version. If a bad release reaches stable, the only available levers are:

  • yank — removes the version from the registry (reversible via unyank), but it's heavy-handed, and the manual does not document whether yanking the current stable version causes stable resolution to fall back to the prior non-yanked version.
  • deprecate — a soft search-ranking signal that, per the manual, does not change channel resolution.

Neither reassigns the channel. So a maintainer who promotes the wrong build to stable cannot cleanly roll the stable pointer back; they must yank (and hope for fallback) or rush a corrected version.

Proposed solution

Provide an explicit downward / withdrawal path, e.g. one of:

  • swamp extension demote <ext> <version> --from-channel stable --channel rc|beta, or
  • allow promote --channel beta|rc (lift the upward-only restriction), or
  • a swamp extension channel unset <ext> <version> --channel stable that re-points stable to the previous stable version.

Either way: document the resulting channel-resolution behavior (which version stable resolves to afterwards). Separately, document yank's effect on channel resolution — whether stable falls back to the prior version after a yank.

Alternatives considered

  • Yank the bad version and republish a corrected one — works but loses the version number and relies on undocumented fallback semantics.
  • Deprecate — does not change which version stable consumers receive.
02Bog Flow
✓OPEN○TRIAGED○IN PROGRESS◉CLOSED+ 1 MOREASSIGNED

Closed

6/11/2026, 5:26:31 PM

No activity in this phase yet.

03Sludge Pulse
stack72 assigned stack726/11/2026, 5:08:20 PM
Editable. Press Enter to edit.

stack72 commented 6/11/2026, 5:26:05 PM

@magistr Thanks for the detailed write-up — the gap around documenting yank's effect on channel resolution is a fair point and something we should address.

After researching how other ecosystems handle this, we're not going to add a demote/withdraw command. Here's why:

Demotion doesn't actually roll back consumers. Swamp is a pull-based registry — once someone has pulled a version from stable, demoting it to rc doesn't change what's in their lock file or on disk. It creates a false sense of rollback without actually undoing anything. The only registries that support demotion (Snap, Google Play) are auto-updating systems where the client always tracks the channel pointer. That's a fundamentally different model.

The recovery path is yank + fix forward, which is the same pattern used by npm, Cargo, PyPI, RubyGems, Terraform, and every other pull-based registry:

  1. swamp extension yank — removes the bad version from resolution so new consumers don't pick it up
  2. Publish a corrected version and promote it to stable

If the version isn't dangerous, just poorly tested, deprecate is the lighter-weight option — it signals "don't use this" without removing it from resolution.

We will make sure yank's effect on channel resolution is clearly documented — specifically, that yanking the current stable version causes stable to fall back to the previous non-yanked stable version.

Sign in to post a ripple.