ContextQMD
Back to Woocommerce

[{release_main_version}] Release `{release_version}`

.linear/release-kickoff-patch.md

11.1.0-dev6.7 KB
Original Source

[{release_main_version}] Release {release_version}

These are the instructions for releasing {release_version}, scheduled for {release_date}.

Perform all the steps below in order. When running any GitHub workflow, ensure you do it from the trunk branch (the default) and input the release version or branch as indicated.

Keep the Release Troubleshooting & Recovery guide handy, in case you encounter any issues.

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 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).
  • 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 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

3. Build the release package

  • Run workflow Release: Bump version number: 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 or pull requests in the {release_milestone} milestone.
  • Run workflow Release: Compile changelog: enter {release_main_version} as Version and leave Release date empty, except when building the package ahead of schedule.
  • Review and merge the PRs that were generated: one against trunk and another one against the release branch. Both are linked in the workflow run.
  • Run workflow Release: Build ZIP file to build the asset and create the GitHub release: enter {release_main_version} as Release branch and check Create GitHub release.
  • Confirm that a draft {release_version} release was created in the repository with an attached woocommerce.zip asset.

4. Upload the release to WordPress.org

5. Deploy to the staging environment

  • Follow the guide to deploy to the staging environment 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.

If a critical issue was detected while monitoring...

  • Request a revert in the staging environment.
  • Pause the release process and do not continue with any steps on this issue. Follow the procedure in the troubleshooting guide instead.

6. Publish the release

  • Run workflow Release: Update stable tag: 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 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}.
  • If this is the stable release of a new major version: move the supported-version floor forward in the security support policy page (last 21 major versions).

7. Post-release tasks

  • Wait at least 1 hour for all automations to complete and make sure to merge any follow-up PRs under the {release_milestone} milestone.
  • Continue monitoring for bugs related to the release for at least 3 days. See the release monitoring guide for more details.