Release: 3.3.0 (redundant PR)

[github-actions]

This is the release pull request for WooCommerce Blocks plugin 3.3.0.

This PR was automatically generated after 3.3.0 release when the release/3.3 branch was left open.

Changelog

---

Bug Fixes

• Fix product element styling class names. (3095)
• Fix discounted price misalignment in Cart block. (3047)
• Display Checkout block with a notice when adding a product sold individually that was already in the cart. (2854)

Various

• Show express payment methods in the Cart block. (3004)

---

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)

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

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, ideally in /docs/testing/releases

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

---

🚀 This pull request was generated by the automations bot triggered by the creation of the branch: release/3.3. cc @haszari

[github-actions]

The release pull request has been created! This checklist is a guide to follow for the remainder of the release process. You can check off each item in this list once completed.

Checklist

• Checkout the release branch locally.
• Create a GitHub milestone for the next release (set the start date as today's date).
• If there are any remaining open issues in the milestone for 3.3.0, 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.
• Copy the changelog from the pull request description into the readme.txt file in the changelog section. Create a new section here for this release, eg.g. = 3.3.0 - 2020-01-20 =.
• Make any other changes to plugin metadata as necessary (no version changes needed, that's handled by script later in the process).
  • readme.txt - support versions changing, reference new blocks if necessary.
  • woocommerce-gutenberg-products-block.php - requirements/tested up to versions etc.
• Push above changes to the release branch.
• Create testing notes for the release. You can usually go through the pull requests linked in the changelog and grab testing notes from each pull. Add the notes to docs/testing/releases and update the docs/testing/releases/README.md index.
• Run npm ci
• Run composer install --no-dev
• Run npm run package-plugin:deploy. This will create a zip of the current branch build locally.
• Copy a link to the release zip into the testing notes you created earlier. 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:
  • At least one other person should test the built zip - ask a teammate to help out.
  • 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.0).
  • 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.
• Go through the description of the release pull request and edit it to update all the sections and checklist instructions there.
• 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.
• Execute npm run deploy
  • Note: the script automatically updates version numbers (commits on your behalf).
  • 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. A GitHub release will automatically be created and this will trigger a workflow that automatically deploys the plugin to WordPress.org.
• Edit release and copy changelog into GitHub release notes.
• The #team-rubik 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
  • Changelog, Version, and Last Updated on WP.org plugin page is correct.
  • Confirm svn tag is correct, e.g. 3.3.0
  • Confirm WooCommerce.com plugin page is updated.
  • Download zip and smoke test.
  • Test updating plugin from previous version.
• Merge this pull request back into main. This may have merge conflicts needing resolved if there are any cherry-picked commits in the release branch.
• Restore the branch if it is deleted. Release branches are kept open for potential patch releases for that version.
• Confirm version on main is correct and has dev suffix (e.g. something like 2.6-dev) for the next version. Note: this should have already been taken care of you by the release deploy script, just verify the versions are updated correctly.
• Update the schedules p2 with the shipped date for the release (Pca54o-1N-p2).
• Clean up the release milestone and Zenhub.
  • Edit the GitHub milestone and add the current date as the due date (this is used to track ship date as well).
  • Close the milestone.
  • Remove any unfinished issues from the Zenhub epics completed by this release and then close the epics.
• Create a pull request for updating the package in WooCommerce core. When a release of Woo Blocks is the last release before code freeze in the WooCommerce core cycle, we need to bump the package version included in WooCommerce core. We do this by adding a PR on WooCommerce Core repo.
  • Create the pull request in the WooCommerce Core Repository that bumps the package version for the blocks package to the version being pulled in.
  • The content for the pull release can follow this example. Essentially you link to all the important things that have already been prepared. Note, you need to make sure you link to all the related documents for the feature plugin releases since the last package version bump in Woo Core.
  • 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.
• Post release announcement on WooCommerce Developer Blog. Use previous posts for inspiration. If the release contains new features, or API changes, explain what's new so Woo devs/builders/merchants can get excited about it. This post can take time to get right - get feedback from the team, and don't rush it :)
  • Ensure the release notes are included in the post verbatim.
  • Don't forget to use category Blocks for the post.
• Update user-facing documentation as needed. When the plugin is released, ensure user-facing documentation is kept up to date with new blocks and compatibility information. The dev team should update documents in collaboration with support team and WooCommerce docs guild. In particular, please review and update as needed:
  • Are there any new blocks in this release? Ensure they have adequate user documentation.
  • Ensure any major improvements or changes are documented.
  • Update minimum supported versions (WordPress, WooCommerce Core) and other requirements where necessary, including:
    • WCCOM product page
    • WooCommerce blocks main documentation page

🚀 This comment was generated by the automations bot triggered by the creation of the branch: release/3.3. cc @haszari

[nerrad]

@haszari This pull needs merged to master.

[haszari]

@haszari This pull needs merged to master.

Dang, I totally thought I'd merged it! Not sure what happened here, thanks for picking up on it.

No.. wait. I think this is a duplicate / extra PR - the real PR has a bunch of extra info, and reviews. @nerrad Perhaps this was autogenerated by the bot because the release branch is left open? I'll leave this open for now (& mark blocked), if we close it the bot might make another one?

[haszari]

@nerrad Maybe the easiest thing is to leave the release branch closed (i.e. change that part of the process). We can always reactivate it for patch release if needed (because we have PR/release changeset id).

[nerrad]

oh I never noticed that, hmm ya looks like re-opening the branch fires off a new create event for the branch. I agree we can leave the branch closed. This might require new tweaks to the bot.

I've created an issue to followup on: woocommerce/automations#31