mirror of https://github.com/rcourtman/Pulse.git synced 2026-10-23 20:25:56 +00:00

Files

T

rcourtman 478a03b9ed Describe releases as the fixed release train everywhere

Since 4 October 2026 releases are mechanical: the release train cuts the
next minor from main 14 days after the last stable (or earlier on
request), soaks the release candidate on Preview for 24 hours, and
promotes it unchanged unless an open release-blocker issue stops it.

The shipped release docs, the promotion policy, the checklist, the source
of truth, several governance pages and two workflow comments still
described the retired model: release lines, steward judgment, 72-hour
soaks, a nightly rehearsal and patch releases scheduled by severity.
State the train's rules once, in the Release Train section of the
promotion policy, checked against the train itself, and point the rest
at it. Remove the unused internal copy of the promotion resolver, which
still enforced the old 72-hour soak.

2026-10-06 12:06:18 +01:00

4.5 KiB

Raw Blame History

Releases and update channels

Use Stable for production and Preview when you want to help test upcoming changes. Preview releases state what is ready to test, what remains uncertain, and how to return to the previous stable version.

Pulse's earlier releases did not consistently give testers enough time between candidates. From October 2026, releases run on a fixed train: a release candidate is cut on a regular schedule, tested as published, and promoted to stable unchanged. These are the commitments for releases going forward, not a claim that earlier releases met them.

Choose your update channel

Channel	Who it is for	What to expect
Stable	Normal use, including production	A release qualified for general use after release-candidate testing. This is the default and recommended channel.
Preview	People willing to test and report problems	Opt-in prereleases. Read the version's maturity, known issues, test instructions, and rollback guidance before installing.

Preview contains different maturity stages, rather than a separate update channel for each stage:

Alpha is incomplete or experimental and intended for tightly controlled testing.
Beta is the normal public testing stage. Its scope should be useful to test, but known gaps and further product changes are expected.
Release candidate (RC) means the build is believed capable of becoming stable without further product changes. It is still a prerelease.

A beta does not become stable directly. It must be followed by a qualified RC. Choosing Preview does not make a beta production-qualified. Pulse's unattended systemd updater remains Stable-only. See Automatic updates for deployment-specific update behaviour.

How releases are prepared

Releases follow a fixed schedule rather than individual judgment.

Cut a candidate from main. Fourteen days after the last stable release, the next release candidate is cut from main, provided main has changed since that release. An important fix that should not wait for the schedule can bring that cut forward, or replace a candidate that is still soaking with a fresh one that starts its own soak. A candidate carries everything merged to main at the cut. Nothing is selected for it or added to it afterwards.
Qualify and publish it. Required checks include targeted tests, installation smoke checks, release-pipeline validation, and recorded rollback instructions. RCs also run the integration checks required for stable releases. Release notes explain the changes, known issues, what testers should exercise, and the rollback target. A tag or successful build alone is not a published release.
Soak it on Preview. The published candidate soaks for 24 hours on the Preview channel.
Promote it unchanged. After a clean soak, the same candidate is promoted to stable. Release metadata may change, but product content cannot.

Cadence and stable promotion

Each release is the next minor version: after 6.5.0 comes 6.6.0. Patch releases are not scheduled.
Only an open issue labelled release-blocker stops a promotion. That label marks something that worked in the current stable release but is broken in the candidate. Each such issue is closed once its fix is on main. When every one is closed, a fresh candidate is cut from main and starts its own 24-hour soak.
Successive candidates for the same version are published at least 24 hours apart. Time spent on a beta does not count towards an RC's soak.
A defect that the current stable release already has is fixed on main and ships in the next release.

An urgent hotfix exception requires active customer harm and a justification recorded in the release notes. Narrow testing may instead use an immutable reporter test image. Such an image is a temporary diagnostic build and cannot be promoted directly to stable.

Taking part in Preview testing

Start with the published release notes. Back up your data, keep the documented rollback version available, and exercise the checks relevant to your installation. You do not need to install every preview.

When reporting a problem, include the exact version, deployment method, expected and observed behaviour, and reproduction steps. Remove credentials and other private information from logs and screenshots. Confirmation that a named test worked is useful too.

4.5 KiB Raw Blame History