Steve-Dee-Designs
/
woocommerce
mirror of https://github.com/woocommerce/woocommerce.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

update release doc 

Add example query to use for helping determine what merged pulls since the last release are missing in the current release milestone.
This commit is contained in:
Darren Ethier 2020-09-14 12:26:55 -04:00
parent 1e8207ffdd
commit 74c8dce1a8
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
plugins/woocommerce-blocks/docs/releases/handling-releases.md
View File

@ -3,7 +3,7 @@
The WooCommerce Blocks project has a number of automations that aid with making releases. The following are the steps you should take for making a release:
* Create a GitHub milestone for the next release.
* Double-check any merged pulls since the last release that should be included in the release notes are assigned to the milestone for this release. **Note:** You don't need to include renovate pull requests in the milestone.
* Double-check any merged pulls since the last release that should be included in the release notes are assigned to the milestone for this release. **Note:** You don't need to include renovate pull requests in the milestone. You can use this query in the pull request search:`is:pr merged:>=2020-09-01 no:milestone` (replace the date with the date of the last release).
* If there are any remaining open issues in the milestone for the release, do a final check with the team to verify none of those *need* to go into the release. After verifying, go through and move any open issues/pulls into the next milestone (except for any that have the `type: blocker` label). After this any `type: blocker` labelled issues must be complete and merged into the release branch (cherry-pick if necessary) before continuing.
* Use the [GitHub UI](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-and-deleting-branches-within-your-repository#creating-a-branch) to create a release branch for the version being released. The format for the branch name should be `release/x.x` where `x.x` is the version being released. If you are doing a patch release, first, make sure you are viewing the correct release branch before creating the new patch branch. This ensures that the new branch is based off of the release branch. So for example if you were doing a patch release for `3.4.1`. You'd select `release/3.4` from the GitHub branch selector and then create a `release/3.4.1` branch.
* A GitHub workflow is kicked off that will do the following: