Myasnikov Daniil
d3df698c43
Listing labelled pull requests cannot establish whether their changes landed on a maintenance branch. Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com> Assisted-by: LLM
1.8 KiB
Release Process
This document provides instructions for AI agents on how to handle release-related tasks.
When to Use
Follow these instructions when the user asks to:
- Create a new release
- Prepare a release
- Tag a release
- Perform release-related tasks
Instructions
For detailed release process instructions, follow the steps documented in:
Quick Reference
The release process is promotion-based — a stable release is a renamed release-candidate, never a hand-cut tag or a rebuild. At a high level it involves:
- Cutting a release candidate (
Cut Pre-release Tagworkflow) and watching its mandatory full E2E. - Promoting the rc (
Promote RCworkflow), which generates the changelog, opens the parkedcozystack/websitedocs PR, and opens the promote PR. - Reviewing and merging the promote PR (no squash-merge).
- Finalize on merge (CI cuts the write-once tag, publishes the release from the merged changelog, and retags the rc images to stable by digest).
- Merging the parked website docs PR once the release is published.
All detailed steps, workflows, and failure modes are documented in docs/release.md.
For a patch release, or any rc cut from a release-X.Y branch, verify the backport state of that branch before tagging: build with go build ./cmd/backport-audit, then run ./backport-audit release-X.Y. It exits non-zero while anything labeled kind/backport / kind/backport-previous for the line has not landed on it, and prints the URLs. See cmd/backport-audit/README.md and Cherry-pick triage before a patch. Do not report a branch as ready to cut on the strength of gh pr list --search "is:merged label:kind/backport" — that lists what was labeled, not what arrived.