Skip to content

docs: QA cuts the release, not a repo maintainer #171

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
tian-lan-landing merged 3 commits into from
Sep 22, 2026
Merged

docs: QA cuts the release, not a repo maintainer #171

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
c1ecb0c
docs: QA cuts the release, not a repo maintainer
tian-lan-landing Sep 22, 2026
c34e771
docs: align release.yml header with QA ownership; mark design doc his…
tian-lan-landing Sep 22, 2026
87a8aaa
Potential fix for pull request finding 'Include production rollout be…
tian-lan-landing Sep 22, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,8 +40,9 @@ All code in the repository can be edited directly, like any other codebase.
Please use [Conventional Commits](https://www.conventionalcommits.org/) for commit messages and PR
titles (`feat:`, `fix:`, `chore:`, …) — the release changelog is grouped by these prefixes.

Releases are cut manually: a maintainer runs the **Release** workflow (Actions → Release → Run
workflow) and chooses the version bump (patch / minor / major). The workflow lands a
Releases are cut manually, and by QA rather than by a repo maintainer: once they have validated
merged `main` against staging, they run the **Release** workflow (Actions → Release → Run workflow)
and choose the version bump (patch / minor / major). The workflow lands a
Comment thread
tian-lan-landing marked this conversation as resolved.
Outdated
Comment thread
Copilot marked this conversation as resolved.
Outdated
`release: x.y.z` commit on `main` (version stamping + changelog), tags it, and creates the GitHub
Release — which triggers publishing. Ordinary PR merges never trigger a release.

Expand Down
13 changes: 7 additions & 6 deletions docs/spec-sync-runbook.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ are maintained as a pair and most decisions here apply to both.
**staging** spec drifts from the committed snapshot, it opens one PR on a fixed branch
(`spec-sync/v1` or `spec-sync/v2`) and announces it in Slack. You review and merge it — the wiring
commit is AI-drafted and **always** needs human review. Merging publishes nothing: QA tests merged
`main` against staging first, and a maintainer dispatches the release only after the API has reached
`main` against staging first, and QA cuts the release themselves once the API has reached
production.

## 1. Where the signal is: `#ade-sdk-pipeline`
Expand Down Expand Up @@ -118,11 +118,12 @@ out"):
```

4. The API reaches **production**.
5. A maintainer dispatches Actions → **Release** → Run workflow and picks the bump
(patch / minor / major). Dispatching **is** the release decision — there is no release PR and no
second confirmation. The workflow stamps the version, prepends the changelog, pushes
`release: x.y.z` to `main`, tags it, and creates the GitHub Release, which triggers
`publish-pypi.yml`.
5. **QA** cuts the release once they have signed off — this step is theirs, not yours:
Actions → **Release** → Run workflow, picking the bump (patch / minor / major). Dispatching
**is** the release decision: there is no release PR and no second confirmation. The workflow
stamps the version, prepends the changelog, pushes `release: x.y.z` to `main`, tags it, and
creates the GitHub Release, which triggers `publish-pypi.yml`. Know this step even though you do
not run it — when a release goes red, diagnosing it usually comes back to you.

**A red release is usually not a bug.** The Release workflow's gate 0 is the full V1 + V2 e2e suite
against the **live production API**, and nothing downstream runs if it goes red. Two ordinary causes:
Expand Down
Loading