docs/release.md had grown into one page that mixed the release model, the CI pipeline, changelogs, signatures, nightlies and the fires seen at release time. A reader looking for one of them read all of it, and an edit to one part reflowed the rest. It now indexes one page per topic under docs/release/. The pages already describe how fixes reach a release line through the backport batch, which the following commits add. Workflows, scripts and tests that named docs/release.md now point at the page that holds the text they mean. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
1.5 KiB
Introduction
Cozystack uses a staged release process to ensure stability and flexibility during development.
There are three types of releases:
- Release Candidates (RC) – Preview versions (e.g.,
v1.2.0-rc.1) used for final testing and validation. - Regular Releases – Final versions (e.g.,
v1.2.0) that are feature-complete and thoroughly tested. - Patch Releases – Bugfix-only updates (e.g.,
v1.2.1) made after a stable release, based on a dedicated release branch.
All three are matched by tags.yaml's regex ^v\d+\.\d+\.\d+(-(alpha|beta|rc)\.\d+)?$. The tag push is the trigger for the whole pipeline. Pre-release tags (-alpha / -beta / -rc) are cut with the Cut Pre-release Tag workflow (manual dispatch from main or release-X.Y) — it pushes the tag as the CI app at the dispatch branch's tip, so GitHub fills base_ref (tags.yaml's Get base branch step refuses tags pushed without a base) and the push triggers tags.yaml (a tag pushed with the default GITHUB_TOKEN would not). Stable vX.Y.Z tags are never pushed by hand at all — they are cut write-once by the promote flow at a PR merge commit. Only -rc.N pre-releases feed the promotion flow (promote-rc.yaml accepts vX.Y.Z-rc.N alone); -alpha.N / -beta.N tags are built and published for download and validated on demand with the e2e-tag.yaml button, but are never promoted to a stable release.