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

Update handling-releases.md 

Add a step around reviewing pull request titles and labels.
This commit is contained in:
Darren Ethier 2020-09-14 12:37:57 -04:00 committed by GitHub
parent 74c8dce1a8
commit 7fb3c23c15
1 changed files with 1 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -5,6 +5,7 @@ The WooCommerce Blocks project has a number of automations that aid with making
* Create a GitHub milestone for the next 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. 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). * 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. * 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.
* Do a review of pull requests in the milestone for the release to make sure all the titles are clear for changelog and add any missing labels for `type` (i.e. `type: bug`, `type: enhancement`, or `skip-changelog` if not needed in changelog etc). This query is handy for doing this: `is:merged is:pr milestone:3.4.0 -label:skip-changelog ` (substitute milestone number with the milestone you are reviewing).
* 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. * 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: * A GitHub workflow is kicked off that will do the following:
* Create throw-away initial commits (GitHub requires a diff between the branch and it's base in order for pull requests to be created). * Create throw-away initial commits (GitHub requires a diff between the branch and it's base in order for pull requests to be created).