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 viaunyank), 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 stablethat 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.
Closed
No activity in this phase yet.
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:
- swamp extension yank — removes the bad version from resolution so new consumers don't pick it up
- 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.