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 checklist (https://github.com/woocommerce/woocommerce-blocks/pull/11660) 

* Update checklist

* Feedback and update patch checklist to match
This commit is contained in:
Mike Jolley 2023-11-14 10:36:05 +00:00 committed by GitHub
parent 02f9d97282
commit 22bc80536f
2 changed files with 60 additions and 88 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

78
plugins/woocommerce-blocks/.github/patch-initial-checklist.md vendored
View File

@ -20,43 +20,47 @@ The release pull request has been created! This checklist is a guide to follow f
- [ ] Run `npm ci`
- [ ] Run `npm run package-plugin:deploy`. This will create a zip of the current branch build locally.
- Note: The zip file is functionally equivalent to what gets released except the version bump.
- [ ] Create the testing notes for the release.
- [ ] For each pull request that belongs to the current release, grab the `User Facing Testing` notes from the PR's description.
- If a PR has the `Should be tested by the development team exclusively` checkbox checked, create a new section called 'Testing notes for the development team' and copy the `User Facing Testing` notes from the PR to this section.
- If a PR has the `Experimental` checkbox checked, do not include it in the testing instructions.
- If a PR has the `Do not include in the Testing Notes` checkbox checked, as the description suggests, do not include it in the release instructions.
- [ ] Add the notes to `docs/internal-developers/testing/releases`
- [ ] Update the `docs/internal-developers/testing/releases/README.md` file index.
- If a PR has the `Should be tested by the development team exclusively` checkbox checked, create a new section called 'Testing notes for the development team' and copy the `User Facing Testing` notes from the PR to this section.
- If a PR has the `Experimental` checkbox checked, do not include it in the testing instructions.
- If a PR has the `Do not include in the Testing Notes` checkbox checked, as the description suggests, do not include it in the release instructions.
- [ ] Add the notes to `docs/internal-developers/testing/releases`
- [ ] Update the `docs/internal-developers/testing/releases/README.md` file index.
- [ ] Copy a link to the release zip you created earlier into the testing notes. To generate the link you can upload the zip as an attachment in a GitHub comment and then just copy the path (without publishing the comment).
- [ ] Commit and push the testing docs to the release branch.
- [ ] Smoke test built release zip using the testing instructions you created:
- Test in a clean environment, e.g. Jurassic.Ninja site.
- Test existing WooCommerce Blocks content works correctly after update (no block validation errors).
- Test to confirm blocks are available and work correctly in oldest supported WordPress version (e.g. 5.3).
- Confidence check - check blocks are available and function.
- Test to confirm new features/fixes are working correctly.
- Test any UI changes in mobile and desktop views.
- Smoke test – test a cross section of core functionality.
- [ ] Ask the porters of Rubik and Kirigami to smoke test the built release zip as well and to approve the PR if everything looks good.
- [ ] Confirm all GitHub checks have passed on this PR prior to approving.
## Smoke testing
Each porter is responsible for testing the PRs that fall under the focus of their own team. Shared functionality should be tested by both porters. This means that the Rubik porter will mostly test checkout blocks and Store API endpoints, while the Kirigami porter will test the product related blocks and Store API endpoints.
- [ ] Smoke test the built release zip. Refer to the [Smoke testing checklist](https://github.com/woocommerce/woocommerce-gutenberg-products-block/blob/trunk/docs/internal-developers/testing/smoke-testing.md) for critical functionality.
- [ ] Test in a clean environment. Create a Jurassic.Ninja site, upload your zip, then smoke test it.
- [ ] Ask the porters of Rubik/Kirigami/Origami to test the built zip as well and to approve the PR if everything looks good. We recommend creating threads of p2 to track which test cases were tested.
- [ ] Confirm all GitHub checks have passed on this PR prior to approving.
After testing:
- If all PRs are testing as expected, continue with the release.
- If one or more PRs are not testing as expected: ping the PR authors and the porter of the relevant team and ask them if the change is a release blocker or not (you can also ping the team lead if any of them is not available). In general, if it's not a regression or there is no product/marketing reason why that PR is a blocker, all other PRs should default to not being blockers.
- If there are blockers: stop the release and ask the PR author to fix them. If the PR author is AFK, ping the porter of their team.
- If some PRs are not testing as expected but they are not blockers: revert the relevant commits, remove the changes from testing steps and changelog, open an issue (or reopen the original one) and proceed with the release.
- If minor issues are discovered during the testing, each team is responsible for logging them in Github.
## Push the button - Deploy
## Deploy the update
- [ ] Make sure you've got `hub` installed (`brew install hub`) and make sure `hub api user` returns JSON with information about your GitHub user account. If it doesn't:
- Create a [GitHub access token](https://github.com/settings/tokens) with the `repo` permission.
- Set the environment variables: `GITHUB_USERNAME` with your GitHub Username, and `GITHUB_TOKEN` with the token you just generated. (You may want to add these to `.bashrc` or the equivalent)
- Run `hub api user` again and ensure JSON with information about your GitHub user account is returned.
- [ ] Execute `npm run deploy`
- **ALERT**: This script will ask you if this release will be deployed to WordPress.org. You should only answer yes for this release **if it's the latest release and you want to deploy to WordPress.org**. Otherwise, answer no. If you answer yes, you will get asked additional verification by the `npm run deploy` script about deploying a patch release to WordPress.org.
## If this release is deployed to WordPress.org
- [ ] An email confirmation is required before the new version will be released, so check your email in order to confirm the release.
- [ ] Edit the [GitHub release](https://github.com/woocommerce/woocommerce-gutenberg-products-block/releases) and copy changelog into the release notes.
- [ ] Edit the [GitHub release](https://github.com/woocommerce/woocommerce-gutenberg-products-block/releases) and copy changelog into the release notes. Ensure there is a release with the correct version, the one you entered above.
- [ ] The `#woo-blocks-repo` slack instance will be notified about the progress with the WordPress.org deploy. Watch for that. If anything goes wrong, an error will be reported and you can followup via the GitHub actions tab and the log for that workflow.
- [ ] After the wp.org workflow completes, confirm the following
- [ ] Confirm svn tag is correct, e.g. [{{version}}](https://plugins.svn.wordpress.org/woo-gutenberg-products-block/tags/{{version}}/)
@ -65,7 +69,7 @@ Each porter is responsible for testing the PRs that fall under the focus of thei
- [ ] Download zip and smoke test.
- [ ] Test updating plugin from previous version.
## After Deploy
## After Workflow completes
- [ ] Move the changes to the changelog, testing steps and required versions that you did in the previous steps to `trunk`. You can do so copy-and-pasting the changes in a new commit directly to `trunk`, or cherry-picking the commits that introduced those changes.
- [ ] Update the schedules p2 with the shipped date for the release (PdToLP-K-p2).
@ -75,39 +79,19 @@ Each porter is responsible for testing the PRs that fall under the focus of thei
This only needs done if the patch release needs to be included in WooCommerce Core. Reviewing and merging the PR is your team's responsibility, except in the case of `Fix Release Request`. In this case, the WooCommerce release manager reviews and merges the PR.
- [ ] Create a pull request for updating the package in WooCommerce core (based off of the WooCommerce core release branch this is deployed for).
- [ ] Create a pull request for updating the package in the [WooCommerce Core Repository](https://github.com/woocommerce/woocommerce/) that [bumps the package version](https://github.com/woocommerce/woocommerce/blob/747cb6b7184ba9fdc875ab104da5839cfda8b4be/plugins/woocommerce/composer.json) for the Woo Blocks package to the version you are releasing. Reviewing and merging the PR is your team's responsibility. [See this example](https://github.com/woocommerce/woocommerce/pull/32627).
- [ ] Set the base branch (the branch that your PR will be merged into) to the correct one. It must be: - `trunk` if the WC Blocks version you are releasing is higher than the one in core (you can find the current WC Blocks version in core in `plugins/woocommerce/composer.json`) - `release/x.y` if the WC Blocks version in core is higher than the one you are releasing (`x.y` must be the version of WC core that will include the version of WC Blocks you are releasing)
- [ ] Increase the version of `woocommerce/woocommerce-blocks` in the `plugins/woocommerce/composer.json` file
- [ ] Inside `plugins/woocommerce/`, run `composer update woocommerce/woocommerce-blocks` and make sure `composer.lock` was updated
- [ ] Run `pnpm --filter=woocommerce changelog add` to create a new changelog file similar to this one [plugins/woocommerce/changelog/update-woocommerce-blocks-7.4.1](https://github.com/woocommerce/woocommerce/blob/5040a10d01896bcf40fd0ac538f2b7bc584ffe0a/plugins/woocommerce/changelog/update-woocommerce-blocks-7.4.1). The file will be auto-generated with your answers. For the _Significance_ entry we’ll always use `patch`. For the changelog enter "Update WooCommerce Blocks to X.X.X".
- [ ] Verify and make any additional edits to the pull request description for things like: Changelog to be included with WooCommerce core, additional communication that might be needed elsewhere, additional marketing communication notes that may be needed, etc.
- [ ] Set the base branch (the branch that your PR will be merged into) to the correct one. It must be:
- `trunk` if the WC Blocks version you are releasing is higher than the one in core (you can find the current WC Blocks version in core in `plugins/woocommerce/composer.json`)
- `release/x.y` if the WC Blocks version in core is higher than the one you are releasing (`x.y` must be the version of WC core that will include the version of WC Blocks you are releasing)
- The content for the pull release can follow [this example](https://github.com/woocommerce/woocommerce/pull/32627).
- [ ] Increase the version of `woocommerce/woocommerce-blocks` in the `plugins/woocommerce/composer.json` file
- [ ] Inside `plugins/woocommerce/`, run `composer update woocommerce/woocommerce-blocks` and make sure `composer.lock` was updated
- [ ] Run `pnpm --filter=woocommerce changelog add` to create a new changelog file similar to this one [plugins/woocommerce/changelog/update-woocommerce-blocks-7.4.1](https://github.com/woocommerce/woocommerce/blob/5040a10d01896bcf40fd0ac538f2b7bc584ffe0a/plugins/woocommerce/changelog/update-woocommerce-blocks-7.4.1). The file will be auto-generated with your answers. For the _Significance_ entry we’ll always use `patch` for WC Blocks patch releases:
```md
Significance: patch
Type: update
Update WooCommerce Blocks to {{version}}
```
- The PR description can follow [this example](https://github.com/woocommerce/woocommerce/pull/32627).
- It lists all the WooCommerce Blocks versions that are being included since the last version that you edited in `plugins/woocommerce/composer.json`. Each version should have a link for the `Release PR`, `Testing instructions` and `Release post` (if available).
- The changelog should be aggregated from all the releases included in the package bump and grouped per type: `Enhancements`, `Bug Fixes`, `Various` etc. This changelog will be used in the release notes for the WooCommerce release. That's why it should only list the PRs that have WooCoomerce Core in the WooCommerce Visibility section of their description. Don't include changes available in the feature plugin or development builds.
- [ ] Build WC core from that branch with `pnpm run --filter='woocommerce' build` (you might need to [install the dependencies first](https://github.com/woocommerce/woocommerce#prerequisites)) and:
### Testing the PR
- [ ] Build WC core from that branch with `pnpm run --filter='woocommerce' build ` (you might need to [install the dependencies first](https://github.com/woocommerce/woocommerce#prerequisites)) and:
- [ ] Make sure the correct version of WC Blocks is being loaded. This can be done testing at least one of the testing steps from the release.
- [ ] Complete the [Smoke testing checklist](https://github.com/woocommerce/woocommerce-gutenberg-products-block/blob/trunk/docs/internal-developers/testing/smoke-testing.md).
- [ ] Verify and make any additional edits to the pull request description for things like: Changelog to be included with WooCommerce core, additional communication that might be needed elsewhere, additional marketing communication notes that may be needed, etc.
- [ ] Assign the corresponding WC version milestone to the PR
- [ ] After the checklist is complete and the testing is done, select the porter of your team to review the PR. Once approved, make sure you merge the PR.
- [ ] Make sure you join the `#woo-core-releases` Slack channel to represent Woo Blocks for the release of WooCommerce core this version is included in.
- [ ] After the checklist is complete and the testing is done, select the porter of your team to review the PR. Once approved, make sure you merge the PR.
## Publish Posts

70
plugins/woocommerce-blocks/.github/release-initial-checklist.md vendored
View File

@ -27,42 +27,37 @@ The release pull request has been created! This checklist is a guide to follow f
- Note: The zip file is functionally equivalent to what gets released except the version bump.
- [ ] Create the testing notes for the release.
- [ ] For each pull request that belongs to the current release, grab the `User Facing Testing` notes from the PR's description.
- If a PR has the `Should be tested by the development team exclusively` checkbox checked, create a new section called 'Testing notes for the development team' and copy the `User Facing Testing` notes from the PR to this section.
- If a PR has the `Experimental` checkbox checked, do not include it in the testing instructions.
- If a PR has the `Do not include in the Testing Notes` checkbox checked, as the description suggests, do not include it in the release instructions.
- If a PR has the `Should be tested by the development team exclusively` checkbox checked, create a new section called 'Testing notes for the development team' and copy the `User Facing Testing` notes from the PR to this section.
- If a PR has the `Experimental` checkbox checked, do not include it in the testing instructions.
- If a PR has the `Do not include in the Testing Notes` checkbox checked, as the description suggests, do not include it in the release instructions.
- [ ] Add the notes to `docs/internal-developers/testing/releases`
- [ ] Update the `docs/internal-developers/testing/releases/README.md` file index.
- [ ] Copy a link to the release zip you created earlier into the testing notes. To generate the link you can upload the zip as an attachment in a GitHub comment and then just copy the path (without publishing the comment).
- [ ] Commit and push the testing docs to the release branch.
- [ ] Smoke test built release zip using the testing instructions you created:
- Test in a clean environment, e.g. Jurassic.Ninja site.
- Test existing WooCommerce Blocks content works correctly after update (no block validation errors).
- Test to confirm blocks are available and work correctly in oldest supported WordPress version (e.g. 5.3).
- Confidence check - check blocks are available and function.
- Test to confirm new features/fixes are working correctly.
- Test any UI changes in mobile and desktop views.
- Smoke test – test a cross section of core functionality.
- [ ] Ask the porters of Rubik and Kirigami to test the built zip as well and to approve the PR if everything looks good.
- [ ] Confirm all GitHub checks have passed on this PR prior to approving.
## Smoke testing
Each porter is responsible for testing the PRs that fall under the focus of their own team. Shared functionality should be tested by both porters. This means that the Rubik porter will mostly test checkout blocks and Store API endpoints, while the Kirigami porter will test the product related blocks and Store API endpoints.
- [ ] Smoke test the built release zip. Refer to the [Smoke testing checklist](https://github.com/woocommerce/woocommerce-gutenberg-products-block/blob/trunk/docs/internal-developers/testing/smoke-testing.md) for critical functionality.
- [ ] Test in a clean environment. Create a Jurassic.Ninja site, upload your zip, then smoke test it.
- [ ] Ask the porters of Rubik/Kirigami/Origami to test the built zip as well and to approve the PR if everything looks good. We recommend creating threads of p2 to track which test cases were tested.
- [ ] Confirm all GitHub checks have passed on this PR prior to approving.
After testing:
- If all PRs are testing as expected, continue with the release.
- If one or more PRs are not testing as expected: ping the PR authors and the porter of the relevant team and ask them if the change is a release blocker or not (you can also ping the team lead if any of them is not available). In general, if it's not a regression or there is no product/marketing reason why that PR is a blocker, all other PRs should default to not being blockers.
- If there are blockers: stop the release and ask the PR author to fix them. If the PR author is AFK, ping the porter of their team.
- If some PRs are not testing as expected but they are not blockers: revert the relevant commits, remove the changes from testing steps and changelog, open an issue (or reopen the original one) and proceed with the release.
- If minor issues are discovered during the testing, each team is responsible for logging them in Github.
## Ensure hub is set up and you're authenticated
- [ ] Make sure you've got `hub` installed (`brew install hub`)
- [ ] Make sure `hub api user` returns JSON with information about your GitHub user account, if it doesn't:
- [ ] Create a [GitHub access token](https://github.com/settings/tokens) with the `repo` permission.
- [ ] Set the environment variables: `GITHUB_USERNAME` with your GitHub Username, and `GITHUB_TOKEN` with the token you just generated. (You may want to add these to `.bashrc` or the equivalent)
- [ ] Run `hub api user` again and ensure JSON with information about your GitHub user account is returned.
## Push the button - Deploy
## Deploy the update
- [ ] Make sure you've got `hub` installed (`brew install hub`) and make sure `hub api user` returns JSON with information about your GitHub user account. If it doesn't:
- Create a [GitHub access token](https://github.com/settings/tokens) with the `repo` permission.
- Set the environment variables: `GITHUB_USERNAME` with your GitHub Username, and `GITHUB_TOKEN` with the token you just generated. (You may want to add these to `.bashrc` or the equivalent)
- Run `hub api user` again and ensure JSON with information about your GitHub user account is returned.
- [ ] Execute `npm run deploy`
- The script will ask you to enter the version number to tag. Please enter the version we're releasing right now. Do not publish any dev tags as a release.
- **ALERT**: This script will ask you if this release will be deployed to WordPress.org. You should answer yes for this release even if it is a pre-release.
@ -92,34 +87,27 @@ Each porter is responsible for testing the PRs that fall under the focus of thei
**🆕 These steps need to be done for every WooCommerce Blocks release that _isn't_ a patch release**. More information can be found here on why: pdToLP-Of-p2.
- [ ] Remind whoever is porter this week to audit our codebase to ensure this [experimental interface document](https://github.com/woocommerce/woocommerce-blocks/blob/trunk/docs/internal-developers/blocks/feature-flags-and-experimental-interfaces.md) is up to date. See Pca54o-rM-p2 for more details.
- [ ] Create a pull request for updating the package in the [WooCommerce Core Repository](https://github.com/woocommerce/woocommerce/) that [bumps the package version](https://github.com/woocommerce/woocommerce/blob/747cb6b7184ba9fdc875ab104da5839cfda8b4be/plugins/woocommerce/composer.json) for the Woo Blocks package to the version you are releasing. Reviewing and merging the PR is your team's responsibility.
- [ ] Create a pull request for updating the package in the [WooCommerce Core Repository](https://github.com/woocommerce/woocommerce/) that [bumps the package version](https://github.com/woocommerce/woocommerce/blob/747cb6b7184ba9fdc875ab104da5839cfda8b4be/plugins/woocommerce/composer.json) for the Woo Blocks package to the version you are releasing. Reviewing and merging the PR is your team's responsibility. [See this example](https://github.com/woocommerce/woocommerce/pull/32627).
- [ ] Increase the version of `woocommerce/woocommerce-blocks` in the `plugins/woocommerce/composer.json` file
- [ ] Inside `plugins/woocommerce/`, run `composer update woocommerce/woocommerce-blocks` and make sure `composer.lock` was updated
- [ ] Run `pnpm --filter=woocommerce changelog add` to create a new changelog file similar to this one [plugins/woocommerce/changelog/update-woocommerce-blocks-7.4.1](https://github.com/woocommerce/woocommerce/blob/5040a10d01896bcf40fd0ac538f2b7bc584ffe0a/plugins/woocommerce/changelog/update-woocommerce-blocks-7.4.1). The file will be auto-generated with your answers. For the _Significance_ entry we’ll always use `minor`. For the changelog enter "Update WooCommerce Blocks to X.X.X".
- [ ] Verify and make any additional edits to the pull request description for things like: Changelog to be included with WooCommerce core, additional communication that might be needed elsewhere, additional marketing communication notes that may be needed, etc.
- The content for the pull release can follow [this example](https://github.com/woocommerce/woocommerce/pull/32627).
The PR description can follow [this example](https://github.com/woocommerce/woocommerce/pull/32627).
- [ ] Increase the version of `woocommerce/woocommerce-blocks` in the `plugins/woocommerce/composer.json` file
- [ ] Inside `plugins/woocommerce/`, run `composer update woocommerce/woocommerce-blocks` and make sure `composer.lock` was updated
- [ ] Run `pnpm --filter=woocommerce changelog add` to create a new changelog file similar to this one [plugins/woocommerce/changelog/update-woocommerce-blocks-7.4.1](https://github.com/woocommerce/woocommerce/blob/5040a10d01896bcf40fd0ac538f2b7bc584ffe0a/plugins/woocommerce/changelog/update-woocommerce-blocks-7.4.1). The file will be auto-generated with your answers. For the _Significance_ entry we’ll always use `minor` for WC Blocks major releases:
- It lists all the WooCommerce Blocks versions that are being included since the last version that you edited in `plugins/woocommerce/composer.json`. Each version should have a link for the `Release PR`, `Testing instructions` and `Release post` (if available).
- The changelog should be aggregated from all the releases included in the package bump and grouped per type: `Enhancements`, `Bug Fixes`, `Various` etc. This changelog will be used in the release notes for the WooCommerce release. That's why it should only list the PRs that have WooCommerce Core in the WooCommerce Visibility section of their description. Don't include changes available in the feature plugin or development builds.
```md
Significance: minor
Type: update
Update WooCommerce Blocks to 7.4.0
```
- The PR description can follow [this example](https://github.com/woocommerce/woocommerce/pull/32627).
- It lists all the WooCommerce Blocks versions that are being included since the last version that you edited in `plugins/woocommerce/composer.json`. Each version should have a link for the `Release PR`, `Testing instructions` and `Release post` (if available).
- The changelog should be aggregated from all the releases included in the package bump and grouped per type: `Enhancements`, `Bug Fixes`, `Various` etc. This changelog will be used in the release notes for the WooCommerce release. That's why it should only list the PRs that have WooCoomerce Core in the WooCommerce Visibility section of their description. Don't include changes available in the feature plugin or development builds.
### Testing the PR
- [ ] Build WC core from that branch with `pnpm run --filter='woocommerce' build ` (you might need to [install the dependencies first](https://github.com/woocommerce/woocommerce#prerequisites)) and:
- [ ] Make sure the correct version of WC Blocks is being loaded. This can be done testing at least one of the testing steps from the release.
- [ ] Complete the [Smoke testing checklist](https://github.com/woocommerce/woocommerce-gutenberg-products-block/blob/trunk/docs/internal-developers/testing/smoke-testing.md).
- [ ] After the checklist is complete and the testing is done, select the porter of your team to review the PR. Once approved, make sure you merge the PR.
- [ ] Verify and make any additional edits to the pull request description for things like: Changelog to be included with WooCommerce core, additional communication that might be needed elsewhere, additional marketing communication notes that may be needed, etc.
### Monthly Releases only
- [ ] Assign the corresponding WC version milestone to the PR
- [ ] After the checklist is complete and the testing is done, select the porter of your team to review the PR. Once approved, make sure you merge the PR.
If this is a monthly release, you'll need to do the following steps as well:
- [ ] Make sure you join the `#woo-core-releases` Slack channel to represent Woo Blocks for the release of WooCommerce core this version is included in.
- [ ] Search the release thread of the WooCommerce core version in WooCommerce P2 (example: p6q8Tx-2gl-p2).