Commit 7db8ffa8af8 for woocommerce
commit 7db8ffa8af8965ab5e5baa1a027b73049fb44a4a
Author: Rafael Meneses <meneses.tio@gmail.com>
Date: Wed Jul 22 04:54:00 2026 -0300
Add readiness review, go/no-go, and a Product DRI to the release process (#66805)
* docs(release): add a Product DRI to the release tracking template
The release tracking issue names only the release lead. Calls with
product implications - is this finding release-blocking, does it ship
with a known-issues note - had no named product owner and were made
informally, if at all.
Add a Product DRI line to the parent tracking template, confirmed per
cycle by the release lead. The readiness review and go/no-go steps in
the sub-issue templates lean on this role.
The field is filled by hand for now; teaching the assignment workflow
to populate it can follow once the role settles.
Refs ARC-1862
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs(release): add a readiness review to the RC run-book
The RC run-book jumped straight into pre-build mechanics - milestone
empty, cherry-picks actioned, stable tag matching. Whether the release
was actually ready to go out - compatibility evidence, open findings,
rollback path - was nobody's explicit step.
Add a readiness review as step 1, run with the Product DRI before the
build starts: QIT sweep results verdicted, every open finding issued
and verdicted, rollback path known, comms ready. The RC is the last
point where finding a problem costs a day instead of a revert.
Refs ARC-1863
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs(release): add a go/no-go step to the stable release run-book
Stable releases shipped on schedule by default - there was no moment
where someone deliberately decided to ship, while there was still time
not to. When concerns existed, they surfaced in ad hoc Slack threads
with no record of what was weighed or decided.
Add a go/no-go as step 1 of the stable run-book: 24-48 hours before
the date, release lead plus Product DRI confirm the RC readiness
verdicts still hold and record go / no-go / go-with-conditions on the
issue, with names. Unscheduled point releases compress this into a
quick recorded confirmation.
Refs ARC-1864
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs(release): document release roles, readiness review, and go/no-go
The run-book checklists say what to check; nothing said why, or who
the roles behind them are. Process knowledge of this kind lived with
the people who built the release tooling, and stopped being available
when they moved on.
Add a readiness guide covering the two roles (release lead, Product
DRI) and the two decision points (readiness review at RC, go/no-go
before stable), and link it from the releases overview. The sub-issue
templates reference this page.
Refs ARC-1862, ARC-1863, ARC-1864
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs(release): describe the process, not its history
The readiness guide narrated how these calls used to happen informally
and why writing them down helps. A standing document describes the
process; the origin story fades and goes stale.
Remove the historical paragraph and two commentary lines, keeping only
what the reader needs to run the process.
Refs ARC-1862
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs(release): point lead assignment at the workflows page
The readiness guide linked "assigned by rotation" to the release
schedule page, which covers cadence, not assignment. The assignment is
documented on the workflows page (Release: Assignment).
Refs ARC-1862
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs(release): anchor the go/no-go on the readiness review, not the RC
The go/no-go checklist in the patch run-book referenced "the RC
sub-issue" and "since the RC". The same template also generates the
run-book for point releases, which have no RC - a scheduled point
release would hit a checklist referencing artifacts that don't exist.
Anchor both items on the readiness review instead, and define what that
review means for point releases: run the readiness criteria over the
changes being shipped as part of the go/no-go. The point-release
section in readiness.md now covers scheduled point releases too, not
only the urgent-fix case.
Raised by tyxla in review of this PR.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
diff --git a/.linear/release-kickoff-patch.md b/.linear/release-kickoff-patch.md
index 89366d96929..18d1cdb3702 100644
--- a/.linear/release-kickoff-patch.md
+++ b/.linear/release-kickoff-patch.md
@@ -10,7 +10,18 @@ Keep the _[Release Troubleshooting & Recovery](https://developer.woocommerce.com
----
-### 1. Pre-build checks
+### 1. Go/no-go
+
+For scheduled stable releases, hold this 24-48 hours before the release date, with the Product DRI (named on the parent tracking issue). Bring in QualityOps and the Atomic contact when staging or monitoring left open questions. See the [readiness guide](https://developer.woocommerce.com/docs/contribution/releases/readiness/) for details.
+
+- [ ] The readiness review is complete and its verdicts still hold.
+- [ ] No new blocking findings since the readiness review (check `#woo-core-releases` threads and the [newest issues]({repository_url}/issues?q=is%3Aissue%20state%3Aopen%20sort%3Acreated-desc)).
+- [ ] Decision recorded as a comment on this issue - **go**, **no-go**, or **go with conditions** - with the names behind it.
+
+For scheduled releases, the readiness review is the one in the RC sub-issue. Point releases have no RC: run the [readiness criteria](https://developer.woocommerce.com/docs/contribution/releases/readiness/) over the changes being shipped as part of this go/no-go. For unscheduled point releases shipping an urgent fix, a quick go/no-go with the Product DRI in `#woo-core-releases` is enough - record the outcome here all the same.
+
+
+### 2. Pre-build checks
- [ ] Confirm [GitHub services](https://www.githubstatus.com/) are operational.
- [ ] Verify no open [issues]({repository_url}/issues?q=is:open+is:issue+milestone:{release_milestone}) or [pull requests]({repository_url}/pulls?q=is:open+is:pr+milestone:{release_milestone}) exist against the `{release_milestone}` milestone. Ping authors as needed to merge or close.
@@ -18,7 +29,7 @@ Keep the _[Release Troubleshooting & Recovery](https://developer.woocommerce.com
- [ ] Confirm the `Stable tag` value [in the readme.txt on the release branch]({repository_url}/blob/{release_branch}/plugins/woocommerce/readme.txt#L7) matches the one [on WordPress.org's `trunk`](https://plugins.trac.wordpress.org/browser/woocommerce/trunk/readme.txt#L7).
-### 2. Build the release package
+### 3. Build the release package
- [ ] Run workflow **[Release: Bump version number]({repository_url}/actions/workflows/release-bump-version.yml)**: enter `{release_main_version}` as _Release branch_ and `stable` as _Type of version bump to perform_.
- [ ] Review and merge the PR that was generated against the release branch. Check for remaining open [issues]({repository_url}/issues?q=is:open+is:issue+milestone:{release_milestone}) or [pull requests]({repository_url}/pulls?q=is:open+is:pr+milestone:{release_milestone}) in the `{release_milestone}` milestone.
@@ -28,7 +39,7 @@ Keep the _[Release Troubleshooting & Recovery](https://developer.woocommerce.com
- [ ] Confirm that a draft `{release_version}` release [was created in the repository]({repository_url}/releases) with an attached `woocommerce.zip` asset.
-### 3. Upload the release to WordPress.org
+### 4. Upload the release to WordPress.org
- [ ] Run workflow **[Release: Upload release to WordPress.org]({repository_url}/actions/workflows/release-upload-to-wporg.yml)**: enter `{release_version}` as _Release tag to upload_ and make sure to check 'I confirm that I want to upload a release to WordPress.org.'
- [ ] Confirm that SVN tag `{release_version}` [exists on WordPress.org SVN](https://plugins.svn.wordpress.org/woocommerce/tags/{release_version}).
@@ -36,7 +47,7 @@ Keep the _[Release Troubleshooting & Recovery](https://developer.woocommerce.com
- [ ] After a few minutes, confirm that [`{release_version}` is available for download](https://downloads.wordpress.org/plugin/woocommerce.{release_version}.zip).
-### 4. Deploy to the staging environment
+### 5. Deploy to the staging environment
- [ ] Follow the [guide to deploy to the staging environment](https://wp.me/PCYsg-18BQ) and monitor for at least {release_monitoring_time} hours after deploy.
- [ ] Share the `#atomic` staging thread in `#woo-core-releases` for visibility. If monitoring surfaces an issue, create a dedicated `#woo-core-releases` thread for that issue.
@@ -47,13 +58,13 @@ Keep the _[Release Troubleshooting & Recovery](https://developer.woocommerce.com
- [ ] Pause the release process and **do not continue with any steps on this issue**. Follow the procedure in the [troubleshooting guide](https://developer.woocommerce.com/docs/contribution/releases/troubleshooting/#deploy-serious-bug) instead.
-### 5. Publish the release
+### 6. Publish the release
- [ ] Run workflow **[Release: Update stable tag]({repository_url}/actions/workflows/release-update-stable-tag.yml)**: enter `{release_version}` as _Version_ and make sure to check 'I confirm that I want to update the stable tag (this will update the SVN and GitHub stable tags).'
- [ ] Publish the `{release_version}` [release draft]({repository_url}/releases) that was previously created, as well as any other `{release_main_version}` drafts that might exist from previous attempts. **Ensure** that "Set as the latest release" is checked for `{release_version}`.
-### 6. Post-release tasks
+### 7. Post-release tasks
- [ ] Wait at least 1 hour for all automations to complete and make sure to merge any follow-up [PRs]({repository_url}/pulls?q=is:open+is:pr+milestone:{release_milestone}) under the `{release_milestone}` milestone.
- [ ] Continue monitoring for bugs related to the release for at least 3 days. See the [release monitoring guide](https://developer.woocommerce.com/docs/contribution/releases/monitoring/) for more details.
diff --git a/.linear/release-kickoff-rc.md b/.linear/release-kickoff-rc.md
index 1ff6570ad51..a56e016b898 100644
--- a/.linear/release-kickoff-rc.md
+++ b/.linear/release-kickoff-rc.md
@@ -10,7 +10,19 @@ Keep the _[Release Troubleshooting & Recovery](https://developer.woocommerce.com
----
-### 1. Pre-build checks
+### 1. Release readiness review
+
+Go through this with the Product DRI (named on the parent tracking issue) before starting the build. The goal is a deliberate "this RC is ready to go out" call, with the evidence in one place. See the [readiness guide](https://developer.woocommerce.com/docs/contribution/releases/readiness/) for details on each item.
+
+- [ ] Review the QIT compatibility regression sweep report for this prerelease. Every introduced issue has a verdict: blocking or not.
+- [ ] Every open finding against this release (bug reports, testing threads, monitoring alerts) has a linked issue and a verdict: release-blocking / fix in a point release / not a bug.
+- [ ] The rollback path for this release is known: who reverts, how, and what revert means for this version (see the [troubleshooting guide](https://developer.woocommerce.com/docs/contribution/releases/troubleshooting/)).
+- [ ] Comms are ready: the changelog is in shape and there's a known-issues list if the verdicts above left anything open.
+
+If an item can't be checked, raise it in `#woo-core-releases` before continuing - delaying an RC is cheaper than reverting a stable.
+
+
+### 2. Pre-build checks
- [ ] Confirm [GitHub services](https://www.githubstatus.com/) are operational.
- [ ] Verify no open [issues]({repository_url}/issues?q=is:open+is:issue+milestone:{release_milestone}) or [pull requests]({repository_url}/pulls?q=is:open+is:pr+milestone:{release_milestone}) exist against the `{release_milestone}` milestone. Ping authors as needed to merge or close.
@@ -18,7 +30,7 @@ Keep the _[Release Troubleshooting & Recovery](https://developer.woocommerce.com
- [ ] Confirm the `Stable tag` value [in the readme.txt on the release branch]({repository_url}/blob/{release_branch}/plugins/woocommerce/readme.txt#L7) matches the one [on WordPress.org's `trunk`](https://plugins.trac.wordpress.org/browser/woocommerce/trunk/readme.txt#L7).
-### 2. Build the release package
+### 3. Build the release package
- [ ] Run workflow **[Release: Bump version number]({repository_url}/actions/workflows/release-bump-version.yml)**: enter `{release_main_version}` as _Release branch_ and `{release_type}` as _Type of version bump to perform_.
- [ ] Review and merge the PR that was generated against the release branch. Check for remaining open [issues]({repository_url}/issues?q=is:open+is:issue+milestone:{release_milestone}) or [pull requests]({repository_url}/pulls?q=is:open+is:pr+milestone:{release_milestone}) in the `{release_milestone}` milestone.
@@ -28,7 +40,7 @@ Keep the _[Release Troubleshooting & Recovery](https://developer.woocommerce.com
- [ ] Confirm that a draft `{release_version}` release [was created in the repository]({repository_url}/releases) with an attached `woocommerce.zip` asset.
-### 3. Upload the release to WordPress.org
+### 4. Upload the release to WordPress.org
- [ ] Run workflow **[Release: Upload release to WordPress.org]({repository_url}/actions/workflows/release-upload-to-wporg.yml)**: enter `{release_version}` as _Release tag to upload_ and make sure to check 'I confirm that I want to upload a release to WordPress.org.'
- [ ] Confirm that SVN tag `{release_version}` [exists on WordPress.org SVN](https://plugins.svn.wordpress.org/woocommerce/tags/{release_version}).
@@ -36,7 +48,7 @@ Keep the _[Release Troubleshooting & Recovery](https://developer.woocommerce.com
- [ ] After a few minutes, confirm that [`{release_version}` is available for download](https://downloads.wordpress.org/plugin/woocommerce.{release_version}.zip).
-### 4. Deploy to the staging environment
+### 5. Deploy to the staging environment
- [ ] Follow the [guide to deploy to the staging environment](https://wp.me/PCYsg-18BQ) and monitor for at least {release_monitoring_time} hours after deploy.
- [ ] Share the `#atomic` staging thread in `#woo-core-releases` for visibility. If monitoring surfaces an issue, create a dedicated `#woo-core-releases` thread for that issue.
@@ -47,6 +59,6 @@ Keep the _[Release Troubleshooting & Recovery](https://developer.woocommerce.com
- [ ] Pause the release process and **do not continue with any steps on this issue**. Follow the procedure in the [troubleshooting guide](https://developer.woocommerce.com/docs/contribution/releases/troubleshooting/#deploy-serious-bug) instead.
-### 5. Publish the release
+### 6. Publish the release
- [ ] Publish the `{release_version}` [release draft]({repository_url}/releases) that was previously created, as well as any other `{release_main_version}` drafts that might exist from previous attempts. **Do not** check "Set as the latest release".
diff --git a/.linear/release-kickoff.md b/.linear/release-kickoff.md
index 2b01fdc3010..54d5b058280 100644
--- a/.linear/release-kickoff.md
+++ b/.linear/release-kickoff.md
@@ -6,6 +6,7 @@ This issue provides visibility on the progress of the release process of WooComm
- **Milestone:** [{release_milestone}]({repository_url}/issues?q=is:open+milestone:{release_milestone})
- **Release branch:** [`{release_branch}`]({repository_url}/tree/{release_branch})
- **Release lead:** {lead_user} ({lead_team})
+- **Product DRI:** _to be confirmed - see [release roles](https://developer.woocommerce.com/docs/contribution/releases/readiness/#release-roles)_
- **Relevant dates:** ([release calendar](https://developer.woocommerce.com/release-calendar/))
- **Feature Freeze:** {date_feature_freeze}
- **Beta 1:** {date_beta1}
@@ -18,6 +19,7 @@ This issue provides visibility on the progress of the release process of WooComm
⚠ Dear release lead:
- Please read this issue carefully and familiarize yourself with the [release process documentation](https://developer.woocommerce.com/docs/contribution/releases/).
+- Confirm the Product DRI for this cycle and edit the line above with their name. The readiness review (RC sub-issue) and the go/no-go (stable sub-issue) need both of you.
- Join the release channels in Slack (`#woo-core-releases`, `#woo-core-releases-notifications`), where discussions happen and notifications are sent.
- For every release in the cycle, there's a corresponding sub-issue. On the date of each release (see schedule above), open the relevant issue and follow the instructions in it.
- Any additional point/patch releases after the first stable must be tracked as well. Run the **[Release: Create Tracking Issue]({repository_url}/actions/workflows/release-create-tracking-issue.yml)** workflow with the version (e.g., `{release_main_version}.1`) to create the sub-issue.
diff --git a/docs/contribution/releases/README.md b/docs/contribution/releases/README.md
index 9498d3265d6..f790f042c84 100644
--- a/docs/contribution/releases/README.md
+++ b/docs/contribution/releases/README.md
@@ -5,11 +5,12 @@ sidebar_label: Releases
# Releasing WooCommerce
-The WooCommerce release process is managed by a rotating release lead. The documentation below outlines the process for managing releases. To get started with a new release, see [Building and Publishing WooCommerce](/docs/contribution/releases/building-and-publishing).
+The WooCommerce release process is managed by a rotating release lead, paired with a per-cycle Product DRI (see [release roles](/docs/contribution/releases/readiness#release-roles)). The documentation below outlines the process for managing releases. To get started with a new release, see [Building and Publishing WooCommerce](/docs/contribution/releases/building-and-publishing).
## Process Overview
* [Building and Publishing](/docs/contribution/releases/building-and-publishing)
+* [Readiness and Go/No-Go](/docs/contribution/releases/readiness)
* [Troubleshooting](/docs/contribution/releases/troubleshooting)
* [Point Releases](/docs/contribution/releases/point-releases)
* [Cherry-picking](/docs/contribution/releases/backporting)
diff --git a/docs/contribution/releases/readiness.md b/docs/contribution/releases/readiness.md
new file mode 100644
index 00000000000..36cc4b30bee
--- /dev/null
+++ b/docs/contribution/releases/readiness.md
@@ -0,0 +1,39 @@
+---
+post_title: Release Readiness and Go/No-Go
+sidebar_label: Readiness and Go/No-Go
+sidebar_position: 4
+---
+
+# 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](/docs/contribution/releases/workflows) 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](/docs/contribution/releases/workflows). The Product DRI is confirmed per cycle on the tracking issue.
+
+## 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 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. 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: release-blocking, fix in a point release, or not a bug.
+* **Rollback path.** Who reverts, how, and what revert means for this version - 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 (24-48 hours before stable)
+
+A deliberate decision to ship, made while there is still time to not ship. The release lead and the Product DRI confirm the readiness verdicts still hold and nothing blocking has appeared since the readiness review, then record the decision on the release sub-issue: **go**, **no-go**, or **go with conditions** - with names.
+
+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](/docs/contribution/releases/monitoring).