2.6.0 followups for release process etc. (#2598)

* Add a pull request template for releases

* add testing instructions for 2.6.0 in a new testing/releases folder

* add create todo list button and fixt typo

* Add additional notes to release process

- Include about creating a release pull request and the template to use.
- Include about the process for creating the package update bump in WooCommerce core.

* add testing docs for 2.6.1 release

* Apply suggestions from code review

Co-authored-by: Mike Jolley <[email protected]>
Co-authored-by: Albert Juhé Lluveras <[email protected]>

* improve wording to account for merging changes to master from the release branch

* Changes to pull request template

- make checklist more assertive instead of inquisitive.
- Provide more direction via notes and leading text in the template.
- include section on devnotes.

* remove section on updating the wiki

Co-authored-by: Mike Jolley <[email protected]>
Co-authored-by: Albert Juhé Lluveras <[email protected]>

Author: 3 people

.github/release_pull_request_template.md

@@ -0,0 +1,88 @@
+This is the release pull request for {version} of the WooCommerce Blocks plugin.
+
+## Communication
+
+<!--
+  This section is for any notes related to communicating the release.
+  Please include any extra details with each item as needed.
+-->
+
+This release introduces:
+
+<!--
+In this section document an overview/summary of what this release includes. You can refer to
+the changelog for more information
+-->
+
+### Prepared Updates
+
+The following documentation, blog posts, and changelog updates are prepared for the release:
+
+<!--
+In this section you are highlighting all the public facing documentation that is related to the
+release. Feel free to remove anything that doesn't apply for this release.
+-->
+
+**Release announcement:** <!-- Link to release announcement post on developer.woocommerce.com (published after release) -->
+
+**Developer Notes** - The following issues require developer notes in the release post:
+
+<!--
+Issues or pulls needing a developer note are labelled with `status: needs-dev-note`. Review
+those and list here as checklist items. You can have different engineers write the notes
+(usually the engineer that did the changes) if needed, but they should be summarized and included in the release post.
+-->
+
+
+**Relevant developer documentation:** <!-- Link(s) to any developer documentation related to the release -->
+
+**Happiness Engineer:** <!-- Link to any special instructions or helpful notes for HE related to this release -->
+
+* [ ] The release includes a changelog entry in the readme.txt?
+
+
+## Quality
+
+<!--
+  This section is for any notes related to quality around the release.
+  Please include any extra details with each item as needed. This can include notes about
+  Why something isn't checked or expanding info on your response to an item.
+-->
+
+* [ ] Changes in this release are covered by Automated Tests.
+     <!--
+      This section is for confirming that the release changeset is covered by automated tests. If not,
+      please leave some details on why not and any relevant information indicating confidence without
+      those tests.
+      -->
+     * [ ] Unit tests
+     * [ ] E2E tests
+     * [ ] for each supported WordPress and WooCommerce core versions.
+
+* This release has been tested on the following platforms:
+     * [ ] mobile
+     * [ ] desktop
+
+* [ ] This release affects public facing REST APIs.
+    * [ ] It conforms to REST API versioning policy.
+
+* [ ] This release impacts **other extensions** or **backward compatibility**.
+    * [ ] The release changes the signature of public methods or functions
+        * [ ] This is documented (see: <!-- Enter a link to the documentation here -->)
+    * [ ] The release affects filters or action hooks.
+        * [ ] This is documented (see: <!-- Enter a link to the documentation here -->)
+
+* [ ] Link to **testing instructions** for this release: <!-- Enter a link to the testing instructions here -->
+
+* [ ] The release has a negative performance impact on sites.
+    * [ ] There are new assets (JavaScript or CSS bundles)
+    * [ ] There is an increase to the size of JavaScrip or CSS bundles) <!-- please include rationale for this increase -->
+    * [ ] Other negative performance impacts (if yes, include list below)
+
+* [ ] The release has positive performance impact on sites. If checked, please document these improvements here.
+
+## Additional Notes
+
+<!--
+  This section is for additional notes related to the release.
+-->

docs/releases/readme.md

@@ -45,6 +45,10 @@ _Outcome_: **Team is aware of release and in agreement about what fixes & featur
     -   For _major_ and _minor_ releases, create branch: `release/X.X`.
     -   For _patch_ releases, the branch should already exist.
 
+#### Create a release pull request
+
+Using the [release pull request template](../../.github/pull_request_template.md), create a pull request for the release branch you just created. This pull request will have changes merged to master but might not be a straight merge if it contains cherry-picked commits. The pull request also contains the checklist to go over as a part of the release along with being a place to contain all planning/communication around the release. The checklist should be completed and the pull request has an approved review from at least one team member before you do the Github deploy or release the plugin to WordPress.org.
+
 ### Patch releases against latest master
 
 If it's determined a patch release will include the latest master:
@@ -67,13 +71,13 @@ This is for releases where just fixes specific to the branch are released and no
     -   Or in some cases, manually craft a new PR with appropriate changes, targeting release branch.
 -   Push the release branch to origin (so changes are in GitHub repo).
 -   Label the PR: `status: cherry-picked 🍒`.
-    
+
 ### Minor/Major releases
 
 - Ensure your local checkout is updated to the tip of the release branch.
 
 
-_Outcome_: **Release branch has all relevant changes merged & pushed.**
+_Outcome_: **Release branch has all relevant changes merged & pushed and there is a corresponding release pull request created for the release.**
 
 ### Prepare release
 
@@ -103,6 +107,8 @@ _Outcome_: **Release branch has `readme.txt` is updated with release details.**
     -   Confidence check - check blocks are available and function.
     -   Test to confirm new features/fixes are working correctly.
     -   Smoke test – test a cross section of core functionality.
+    -   Tests performed should be recorded and listed in the release pull request.
+-   Ask a team member to review the changes in the release pull request and for anyone who has done testing that they approve the pull request. **Remember release pull requests are just used for tracking the release and are not merged into master**.
 
 _Outcome_: **Confident that source code is ready for release: intended fixes are working correctly, no release blockers or build issues.**
 
@@ -137,14 +143,28 @@ _Outcome_: **Customers can install/update via WPORG; WPORG plugin page is up to
 
 #### Update `master` with release changes
 
--   Ensure changelog is up to date on master.
+-   Merge the release branch back into master (without the branch being up to date with master). This may have merge conflicts needing resolved if there are cherry-picked commits in the release branch.
+-   Do not delete the branch (release branches are kept open for potential patch releases for that version)
 -   For _major_ & _minor_ releases, update version on master with dev suffix, e.g. [`2.6-dev`](https://github.com/woocommerce/woocommerce-gutenberg-products-block/commit/e27f053e7be0bf7c1d376f5bdb9d9999190ce158).
 
 #### Clean up release milestone / Zenhub
 
 -   Edit the milestone and add the current date as the due date (this basically is used for easy reference of when the milestone was completed).
 -   Close the milestone.
 -   If you didn't release a patch release, create a milestone for the next minor release.
+-   Close any epics that are completed as of this release and remove any unfinished issues in that from the epic.
+
+#### Create pull request for updating the package in WooCommerce core.
+
+If the tagged release should be updated in WooCommerce core, do this immediately following our release.
+
+- Create the pull request in the [WooCommerce Core Repository](https://github.com/woocommerce/woocommerce/) that [bumps the package version](https://github.com/woocommerce/woocommerce/blob/master/composer.json) for the blocks package to the version being pulled in.
+- Copy the release pull request notes for that tag (and merge any notes from previous tags if you're bumping up from non consecutive versions) into the pull request description.
+- Run through the testing checklist to ensure everything works in that branch for that package bump. **Note:** Testing should include ensuring any features/new blocks that are supposed to be behind feature gating for the core merge of this package update are working as expected.
+- 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.
+- After the checklist is complete and the testing is done, it will be up to the WooCommerce core team to approve and merge the pull request.
+
+*Outcome:* The package is updated in WooCommerce core frequently and successfully merged to WooCommerce master as a stable release..
 
 ## Appendix: Versions
 

docs/testing/releases/260.md

@@ -0,0 +1,124 @@
+[![Create Todo list](https://raw.githubusercontent.com/senadir/todo-my-markdown/master/public/github-button.svg?sanitize=true)](https://git-todo.netlify.app/create)
+
+## Testing Notes and ZIP for testing
+
+**Zip File for testing:**
+[woocommerce-gutenberg-products-block.zip](https://github.com/woocommerce/woocommerce-gutenberg-products-block/archive/v2.6.0.zip)
+
+
+### Cart and Checkout Blocks
+
+[See testing notes here](https://github.com/woocommerce/woocommerce-gutenberg-products-block/tree/master/docs/testing/cart-checkout)
+
+### All Products
+
+- All of these tests should be done in Safari, Chrome, and Firefox (latest version).
+- Also validate the behaviour of the block in mobile views vs desktop.
+
+* [ ] Verify the block can be added to a new page.
+* [ ] Verify only one instance of the block can be added to a page/post.
+* [ ] Verify the various settings and configuration for the block in the editor works as expected for the given UI.
+* [ ] Verify the block functions as expected for the given configuration on the frontend of the site.
+* [ ] For an instance of this block setup on a post in an earlier release, verify that upgrading to this release doesn't break the block functionality in the frontend or in the editor.
+
+#### Specific changes to test for in this release.
+
+* [ ]  When editing the All Products block, verify that when you change the default sorting options in the inspector controls for the block that the corresponding filter dropdown in the block preview updates as expected (see highlighted areas below):
+
+![example affected areas](https://user-images.githubusercontent.com/2207451/71814247-15521400-307c-11ea-92da-8f4073492397.png)
+
+* [ ] Verify that an error notice is shown in the All Products block if you try to add a product to the cart (using the Add to Cart button) if the product is out of stock or is sold individually and there is already an instance of that product in the cart.
+
+### Filter blocks
+
+These blocks are used in tandem with the All Products block to provide filtering options on the content rendered by the All Products block. They include:
+
+- Filter Products By Attribute
+- Filter Products By Price
+- Active Product Filters
+
+These blocks can be tested by adding them to the same page as the All Products block as the selected values in these blocks affects the products displayed by the All Products block.
+
+* [ ] General testing involves setting up the filter blocks and verifying the the various configurations for the blocks work as expected in the editor (for settings) and the frontend (according to how the block was configured). Validate that when various filters are applied the expected results are shown in the All Products block.
+
+#### Specific changes to test for in this release.
+
+**Testing the price filter block with various settings around taxes and prices**
+
+One fix in this release for this block is that when the price display setting (including or excluding tax) for WooCommerce differs from the price entered setting (prices input including or excluding tax), the displayed prices for filtered results from the entered Price Filter block might appear to be a mismatch (when it's querying based on the prices _saved to the database_). With this release, this is fixed so that no matter how WooCommerce is configured for displaying or saving prices respective to taxes, the displayed products will have prices matching the expected range set via the price filter block.
+
+To test:
+* [ ] In WooCommerce > Settings > Taxes, **choose to enter prices inclusive of tax, but display prices excluding tax.** Test that filters work as expected for the blocks.
+* [ ] In WooCommerce > Settings > Taxes, **choose to enter prices exclusive of tax, but display prices including tax**. Test that filters work on products.
+
+**And/Or labelling in Active Filters block**
+
+* [ ] Setup various filter blocks so that some are set to `any` type filtering and others are set to `all` type filtering.
+* [ ] Add the Active Filters block to the same post/page.
+* [ ] Verify that when you apply filters on the frontend, the Active Filter block updates it's text to match the type of filtering being done.
+
+**Dropdown display style to Attribute Filter block**
+
+This release introduces a dropdown display style for the Filter Products by Attributes block (for both AND and OR type queries). Expected result:
+
+![dropdown display style](https://user-images.githubusercontent.com/3616980/69569869-db8ee780-0fbe-11ea-80f9-52fd95c9be20.gif)
+
+To test:
+
+* [ ] Create a post with a Filter Products by Attribute block and select the Dropdown option in _Display style_ settings.
+* [ ] Preview the post and interact with the filter (search terms, add them, remove them, repeat only using the keyboard, using a screen-reader etc).
+* [ ] Verify everything works as expected for the ui/ux behaviour and for the returned results in the All Products block.
+* [ ] This should work for either "and" or "or" filtering.
+
+**Add option to display an "apply filter button" for the Filter Products by Attribute block**
+
+* [ ] Create a post with an Filter Products by Attribute block and All products block
+* [ ] For the Filter Products by Attribute block, enable the _Filter Button_ option.
+* [ ] Preview the post and verify selecting/unselecting options doesn't update the _All Products_ block until you press the _Go_ button.
+
+### All Product Grid based blocks
+
+All of these blocks share a common ancestor for the PHP side registration, so it's good to test them together. These blocks include:
+
+- Top Rated Products
+- Best Selling Products
+- On Sale Products
+- Products By Attribute
+- Hand-Picked Products
+- Products by Category
+- Products by Tag
+- Newest Products
+
+#### Specific changes to test for in these blocks for this release:
+
+* [ ] Verify that if there are no products on sale, the On Sale Products block shows this placeholder in the editor:
+
+![On Sale Products placeholder](https://user-images.githubusercontent.com/90977/71984453-c2fe2800-3220-11ea-9b6e-fd3c9ca2ece2.png)
+
+* [ ] For any of the product grid blocks, verify that when a fresh instance of the block is added to the editor, it defaults to 3 rows and 3 columns for the grid.
+* [ ] Verify that changing any of the values for the grid "sticks" and persists across saves. Also verify it shows as expected and configured on the frontend.
+* [ ] For any of the product grid blocks, for an instance of the block setup on a post in an earlier release with no changes to it's settings, verify that upgrading to this release doesn't break the block functionality in the frontend or in the editor (However note that the grid will change from the default of 1 in the earlier release to 3 in the recent release automatically).
+* [ ] Same test as above, except in the earlier release, change the grid to something other than 1 row and save. When upgrading to the new release the setting for the grid should have persisted with the block.
+
+### Other blocks
+
+There are a number of other specific focuses for testing for changes in this release for other blocks:
+
+#### Featured Product Block
+
+In this fix, when a product is changed for an existing featured product block, the link in the button updates to the page for the new product. Note, if there is a custom url applied when the product is changed, this will be replaced by the url to the product (that's expected).
+
+To test:
+
+* [ ] Verify any existing instance of this block in a previous release does not show any errors in the editor when updating to this release.
+* [ ] Verify that if you edit the block and change the product it uses, the button url will update as well.
+
+#### Product Categories Block
+
+Support was added for showing category images in the Product Categories block. The following expectations:
+
+- For the "List" display style the toggle option for showing category images is available (and is disabled by default).
+- This option is not available for the "Dropdown" display style.
+- When the option is toggled to "Show Category Image", images for categories are shown per category item in the list.
+
+* [ ] Verify the new option works as expected according to the above both in the editor and in the frontend.

docs/testing/releases/261.md

@@ -0,0 +1,18 @@
+Release build zip:
+[woocommerce-gutenberg-products-block.zip](https://github.com/woocommerce/woocommerce-gutenberg-products-block/archive/v2.6.1.zip)
+
+## To test:
+
+1. View your stock table (`wc_reserved_stock`) in the database
+2. Go to checkout with some items in the cart
+3. Check the stock table is updated with a new row
+4. Refresh the checkout page.
+5. Check that the expires column is updated only
+
+To test stock table creation:
+
+_Note: assuming you are using a development site where you are okay with losing the data._
+
+1. Delete the `wc_reserved_stock` table.
+2. Visit anywhere in the WordPress admin.
+3. Verify the `wc_reserved_stock` table was re-created.

docs/testing/releases/README.md

@@ -0,0 +1,4 @@
+Every release includes specific testing instructions for features and bug fixes added. This is a list of the available release testing instruction docs:
+
+- [2.6.0](./260.md)
+    - [2.6.1](./261.md)