Grilling: Release cadence + stable/testing channel split #43

New Issue

2026-09-02T19:46:16Z

xavierk commented

2026-09-02 19:46:16 +00:00

Parent map: Fenris deb + rpm release plan

Question

Given the channel locked to the self-hosted Gitea Debian/RPM registry (free-form dists, no native stable/testing concept), decide release cadence, and whether a stable/testing channel split is needed at all. If needed, how is it expressed — separate dist names, separate owner/org, manual dual-upload, or deferred until real users demand it?

Parent map: [Fenris deb + rpm release plan](https://git.bongbetic.com/xavierk/Fenris/issues/33) ## Question Given the channel locked to the self-hosted Gitea Debian/RPM registry (free-form dists, no native stable/testing concept), decide release cadence, and whether a stable/testing channel split is needed at all. If needed, how is it expressed — separate dist names, separate owner/org, manual dual-upload, or deferred until real users demand it?

xavierk added the wayfinder:grilling label 2026-09-02 19:46:25 +00:00

xavierk added this to the Wayfinder: Fenris deb + rpm release plan milestone 2026-09-02 19:46:25 +00:00

xavierk added a new dependency 2026-09-02 19:46:26 +00:00

#42 Task: Compose release spec + ADR amending 0004

xavierk self-assigned this 2026-09-02 20:06:57 +00:00

xavierk commented

2026-09-02 20:09:33 +00:00

Resolution

All recommendations accepted (2 grilling rounds).

No stable/testing channel split. Single channel. A testing dist on the free-form Gitea registry would be permanent clutter (registry retains every version forever, no cleanup REST API — #35), there are no CI runners to feed it (#37), and retained old versions already let users pin anything. Deferred until real users demand it; recorded in map fog.

On-demand release cadence. Release happens when user-visible changes or fixes accumulate — no calendar promise, no empty releases. Manual GPG import→sign→delete per release (#39) makes calendar cadence pure ceremony.

Plain semver. Tag vX.Y.Z = pyproject version = package version <X.Y.Z>-1. Major = breaking CLI/config/unit behavior; minor = feature; patch = fix. Schema changes ride their natural bump — no forced-major discipline, because downgrade is unsupported (below) and the only real contract is CLI/config/unit behavior.

Downgrade unsupported. Registry serves all versions, so users can attempt it, but no promise: forward-only store migration (ADR 0004) means older binary over newer store is a store fault, not a supported state. Rollback = restore store snapshot, then install old release. Procedure documented in release spec (#42), not built for.

No RC ceremony — fix-forward. Pre-release builds never touch the registry. Mistakes in a shipped release → revision bump (-2, -3 — already locked in #38) and re-upload; registry 409 on duplicate version+revision makes this the only path anyway.

Tag ↔ release-entry coupling. A release = tag + registry upload + Gitea release entry with human-readable notes + SHA256SUMS. Bare tags are forbidden — a tag without a completed release entry is a mistake, not a release.

No frequency SLA. No "security bugs ship within N days" promise; users watch releases.

Context: CONTEXT.md gained Release and Rollback glossary terms.

Ticket #42 (Compose release spec + ADR amending 0004) unblocked; cadence/split/rollback/downgrade/semver sections of the spec now decided.

## Resolution All recommendations accepted (2 grilling rounds). **No stable/testing channel split.** Single channel. A testing dist on the free-form Gitea registry would be permanent clutter (registry retains every version forever, no cleanup REST API — #35), there are no CI runners to feed it (#37), and retained old versions already let users pin anything. Deferred until real users demand it; recorded in map fog. **On-demand release cadence.** Release happens when user-visible changes or fixes accumulate — no calendar promise, no empty releases. Manual GPG import→sign→delete per release (#39) makes calendar cadence pure ceremony. **Plain semver.** Tag `vX.Y.Z` = pyproject version = package version `<X.Y.Z>-1`. Major = breaking CLI/config/unit behavior; minor = feature; patch = fix. Schema changes ride their natural bump — no forced-major discipline, because downgrade is unsupported (below) and the only real contract is CLI/config/unit behavior. **Downgrade unsupported.** Registry serves all versions, so users can *attempt* it, but no promise: forward-only store migration (ADR 0004) means older binary over newer store is a store fault, not a supported state. Rollback = restore store snapshot, then install old release. Procedure documented in release spec (#42), not built for. **No RC ceremony — fix-forward.** Pre-release builds never touch the registry. Mistakes in a shipped release → revision bump (`-2`, `-3` — already locked in #38) and re-upload; registry 409 on duplicate version+revision makes this the only path anyway. **Tag ↔ release-entry coupling.** A release = tag + registry upload + Gitea release entry with human-readable notes + SHA256SUMS. Bare tags are forbidden — a tag without a completed release entry is a mistake, not a release. **No frequency SLA.** No "security bugs ship within N days" promise; users watch releases. Context: `CONTEXT.md` gained **Release** and **Rollback** glossary terms. Ticket #42 (Compose release spec + ADR amending 0004) unblocked; cadence/split/rollback/downgrade/semver sections of the spec now decided.

xavierk closed this issue

2026-09-02 20:09:34 +00:00

xavierk referenced this issue

2026-09-02 20:10:11 +00:00

Fenris deb + rpm release plan #33

xavierk referenced this issue

2026-09-02 20:14:58 +00:00

Task: Compose release spec + ADR amending 0004 #42

xavierk referenced this issue from a commit

2026-09-02 21:11:31 +00:00

docs: release & packaging spec + ADR 0007 amending 0004 (map #33, task #42)

Sign in to join this conversation.