Release Readiness and Go/No-Go

Two explicit decision points anchor every release cycle. Both live as checklists in the release tracking sub-issues, so each release leaves a written trail of what was checked, what was decided, and by whom. This page explains what each point is for; the checklists themselves are in the sub-issues the Release: Assignment workflow creates.

Release roles

Each cycle has two named owners, listed on the parent tracking issue:

• Release lead (engineering) - runs the release process end to end: builds, publishes, monitors, and executes the run-books.
• Product DRI - the product-side counterpart. Joins the readiness review at RC and the go/no-go before stable, and owns the product read on open findings: what blocks the release, what waits for a point release, and what ships with a known-issues note.

The release lead is assigned by rotation via the Release: Assignment workflow. The Product DRI role is covered by two standing Product seats in Slack's @woo-core-release group. Their names are on the tracking issue. If you're unsure who to loop in, ping the handle.

The handle also holds a standing set of engineering members and the current and previous release leads, who rotate at each feature freeze.

Readiness review (at RC)

The RC is the last point where finding a problem is cheap: nothing has shipped, and delaying costs a day, not a revert. The review runs before the RC build starts and answers one question - is there anything we know about that should stop this release?

The RC build doesn't exist yet when the review runs, so it works from the latest beta and from everything reported since feature freeze. Each item is recorded as a comment on the RC sub-issue on GitHub: the evidence checked and the verdict.

The checklist covers four areas:

• Compatibility evidence. The QIT compatibility regression sweep runs automatically against each prerelease and reports which extension versions the release would break. The review reads the latest beta's sweep. Introduced issues need a verdict, not just a look.
• Open findings. Bug reports, testing threads, and monitoring alerts against the release each get a linked issue and a verdict per the release decision matrix: release-blocking, fix in a point release, next release, or not a bug. The places to check are the comments on the cycle's pre-release notes post, the WordPress.org support forum, the canonical extensions testing post, and GitHub issues opened since feature freeze.
• Rollback path. Who reverts, how, and what a revert would not undo for this version - database migrations, new settings - answered before it's needed, not during an incident.
• Comms. Changelog in shape, and a known-issues list when verdicts left something open.

Go/no-go (after RC staging, before the stable build)

A deliberate decision to ship, made while there is still time to not ship. It runs once the RC has finished its staging monitoring - holding it earlier would mean deciding before the RC has been seen on real sites. The release lead and the Product DRI confirm the readiness verdicts still hold, review the RC's sweep and staging thread, and note any fix merged after the RC and whether it ran on staging. Then they record the decision as a comment on the release sub-issue on GitHub: go, no-go, or go with conditions - with names.

The RC stays on staging for at least 24 hours before the go/no-go. The release lead can wait longer, for example when a finding is still open or a fix merged after the RC hasn't run on staging.

Recorded decisions are the input for release retrospectives and future updates to these checklists.

For point releases

Point releases have no RC, so both decision points fold into the go/no-go on the release sub-issue: the release lead and the Product DRI run the readiness criteria above over the changes being shipped, then record the decision. An unscheduled point release shipping an urgent fix compresses this further: a quick go/no-go with the Product DRI in #woo-core-releases, recorded on the release sub-issue. The criteria for whether an issue warrants a point release at all are in Release Monitoring.