Before 1.0 a release cut leaves every earlier release on offer: nothing removes the previous Releases and their downloads, and the recorded rule keeps the newest release of each version line rather than only the newest release. The product thinker ruled on 2026-10-14 that nothing older than the newest release is offered before 1.0, and the eight earlier Releases (v0.11.1 to v0.14.0) were deleted by hand that day, tags kept. iss-282 records the missing executor for the older newest-per-line rule.

Frontmatter

.abcd/work/issues/open/iss-2610141938299842-previous-releases-are-not-auto-removed.md
open on GitHub ↗ · commit history ↗

mentions2

• dcn-26101400000000032026-10-14 — Before 1.0 only the newest release is offered: the product thinker ruled, after the v0.14.1 cut, "We don't want to offer them prior to 1.0", choosing "Only v0.14.1" over the recorded newest-per-line rule (brief, launch chapter; draft itd-70), which would also have kept v0.13.4, v0.12.0 and v0.11.1. The eight earlier GitHub Releases (v0.14.0, v0.13.4, v0.13.3, v0.13.2, v0.13.1, v0.13.0, v0.12.0, v0.11.1) and their assets were deleted by hand that evening; their tags and the git history stay, so each is still buildable from its tag. Automating the removal at every cut, and changing the recorded rule to match, is iss-2610141938299842 ("auto remove previous ones"); iss-282 holds the older newest-per-line executor gap. Not chosen: newest per line, which keeps older builds on offer.
• iss-282The retention prune has no executor: ComputeRetention renders the newest-per-line plan on every cut (brief section 3) and ship.go names GitHub Release + retention prune as a later phase, so superseded patches (v0.5.0, v0.4.0 today) stay published until someone deletes them by hand from the plan. First rung: a documented manual prune after each publish (gh release delete, tags kept for record); the executor belongs in the release workflow after that proves out