Update Release Template and Docs (https://github.com/woocommerce/woocommerce-blocks/pull/3524)
* Remove release docs from plugin * Clarify text in release checklists
This commit is contained in:
Mike Jolley
GitHub
parent
bc40247d70
commit
7bbe4926f5
|
|
@ -2,25 +2,28 @@ The release pull request has been created! This checklist is a guide to follow f
|
|||
|
||||
* [ ] Checkout the release branch locally.
|
||||
|
||||
## Initial Prep - changelog and meta data changes.
|
||||
## Initial Preparation
|
||||
|
||||
The below only needs done if this patch release is the **_latest_** release of the plugin.
|
||||
|
||||
* [ ] Copy the changelog from the pull request description into the `readme.txt` file to the top of the changelog section. Create a new section here for this release, eg. `= {{version}} - 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.
|
||||
* [ ] Add the changelog to `readme.txt`
|
||||
* [ ] Add the version and date to the changelog section within `readme.txt`, e.g. `= {{version}} - YYYY-MM-DD =`
|
||||
* [ ] Copy the changelog from the pull request description above into this new section
|
||||
* [ ] Update compatibility sections (if applicable). __Note:__ Do not change the stable tag or plugin version; this is automated.
|
||||
* [ ] Update _Requires at least_, _Tested up to_, and _Requires PHP_ sections at the top of `readme.txt`.
|
||||
* [ ] Update _Requires at least_, _Requires PHP_, _WC requires at least_, and _WC tested up to_ at the top of `woocommerce-gutenberg-products-block.php`
|
||||
* [ ] Push above changes to the release branch.
|
||||
|
||||
## Testing Notes and Testing
|
||||
## Write Testing Notes
|
||||
|
||||
When creating testing notes, please write them from the perspective of a "user" (merchant) familiar with WooCommerce. So you don't have to spell out exact steps for common setup scenarios (eg. "Create a product"), but do be specific about the thing being tested. Include screenshots demonstrating expectations where that will be helpful.
|
||||
|
||||
* [ ] 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.
|
||||
* Note, make sure to differentiate between things in the testing notes that only apply to the feature plugin and things that apply when included in WooCommerce core as there may be variations there.
|
||||
Additionally, make sure to differentiate between things in the testing notes that only apply to the feature plugin and things that apply when included in WooCommerce core as there may be variations there.
|
||||
|
||||
* [ ] Run `npm ci`
|
||||
* [ ] 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).
|
||||
* [ ] 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`
|
||||
* [ ] Update the `docs/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:
|
||||
* At least one other person should test the built zip - ask a teammate to help out.
|
||||
|
|
|
|||
|
|
@ -2,22 +2,27 @@ The release pull request has been created! This checklist is a guide to follow f
|
|||
|
||||
* [ ] Checkout the release branch locally.
|
||||
|
||||
## Initial Prep - changelog and meta data changes
|
||||
## Initial Preparation
|
||||
|
||||
* [ ] Copy the changelog from the pull request description into the `readme.txt` file to the top of the changelog section. Create a new section here for this release, eg. `= {{version}} - 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.
|
||||
* [ ] Add the changelog to `readme.txt`
|
||||
* [ ] Add the version and date to the changelog section within `readme.txt`, e.g. `= {{version}} - YYYY-MM-DD =`
|
||||
* [ ] Copy the changelog from the pull request description above into this new section
|
||||
* [ ] Update compatibility sections (if applicable). __Note:__ Do not change the stable tag or plugin version; this is automated.
|
||||
* [ ] Update _Requires at least_, _Tested up to_, and _Requires PHP_ sections at the top of `readme.txt`.
|
||||
* [ ] Update _Requires at least_, _Requires PHP_, _WC requires at least_, and _WC tested up to_ at the top of `woocommerce-gutenberg-products-block.php`
|
||||
* [ ] Push above changes to the release branch.
|
||||
|
||||
## Testing Notes and Testing
|
||||
## Write Testing Notes
|
||||
|
||||
When creating testing notes, please write them from the perspective of a "user" (merchant) familiar with WooCommerce. So you don't have to spell out exact steps for common setup scenarios (eg. "Create a product"), but do be specific about the thing being tested. Include screenshots demonstrating expectations where that will be helpful.
|
||||
|
||||
Additionally, make sure to differentiate between things in the testing notes that only apply to the feature plugin and things that apply when included in WooCommerce core as there may be variations there.
|
||||
|
||||
* [ ] Run `npm ci`
|
||||
* [ ] Run `npm run package-plugin:deploy`. This will create a zip of the current branch build locally.
|
||||
* [ ] 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.
|
||||
* Note, make sure to differentiate between things in the testing notes that only apply to the feature plugin and things that apply when included in WooCommerce core as there may be variations there.
|
||||
* [ ] 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`
|
||||
* [ ] Update the `docs/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:
|
||||
|
|
|
|||
|
|
@ -30,10 +30,6 @@ If you want to see what we're working on for future versions, or want to help ou
|
|||
- [Editor Components](assets/js/editor-components)
|
||||
- [Other Docs](./docs)
|
||||
|
||||
### Contributing
|
||||
|
||||
- [Publishing a release](docs/releases/readme.md)
|
||||
|
||||
## Installing the plugin version
|
||||
|
||||
We release a new version of WooCommerce Blocks onto WordPress.org every few weeks, which can be used as an easier way to preview the features.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ The WooCommerce Blocks Handbook provides documentation for designers and develop
|
|||
| Document | Description |
|
||||
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| [Contributing](contributors/getting-started.md) | These documents explain how you can contribute to the development of the blocks plugin, development best practices, and how to help with testing. |
|
||||
| [Releases](releases/readme.md) | These documents cover how to release and test new versions of the blocks plugin. |
|
||||
| [Blocks](blocks/README.md) | This documentation covers functionality specific to certain Blocks. |
|
||||
| [Block Client APIs](block-client-apis/README.md) | This documentation covers API interfaces within Blocks. In most cases, these docs describe APIs and interfaces that are internal only, and thus are provided to assist with developing the blocks in this repository. Documentation will tend to focus on high level overviews. |
|
||||
| [Store API (REST API)](../src/StoreApi/README.md) | These documents cover the Store API used to get product data on the frontend. |
|
||||
|
|
|
|||
|
|
@ -1,65 +0,0 @@
|
|||
# Handling Releases
|
||||
|
||||
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. 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.
|
||||
* 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.
|
||||
* 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).
|
||||
* Notify in the team slack channel that the workflow has started.
|
||||
* Create a pull request using either the template for the [release pull request](../../.github/release-pull-request.md) or [patch release pull request](../../.github/patch-release-pull-request.md) if this is for a patch version.
|
||||
* Create a comment in the new pull request with a checklist for doing the release. The checklist is also from a [template](../../.github/release-initial-checklist.md) ([patch release checklist template](../../.github/patch-initial-checklist.md)).
|
||||
* Notify in the team slack channel that the workflow is completed.
|
||||
* Work through the checklist in the pull request.
|
||||
|
||||
## Release Pull Requests (and templates)
|
||||
|
||||
To aid with the quality of our releases and also serve as a primary communication channel for releases that end up pulled into WooCommerce core via package dependency, every release begins with a _release pull request_. This pull request has a standard description that gets filled out with details about the release and a checklist (in a comment on the pull request) to use for doing the release.
|
||||
|
||||
There are two sets of templates that are used for creating the release pull request.
|
||||
|
||||
- Major/Minor versions use the [release pull request](../../.github/release-pull-request.md) and [release checklist](../../.github/release-initial-checklist.md) templates.
|
||||
- Patch versions use the [patch release pull request](../../.github/patch-release-pull-request.md) and [checklist](../../.github/patch-initial-checklist.md) templates.
|
||||
|
||||
Any changes to to the release process can be updated in those templates. The GitHub automation parses the templates through [handlebars](https://handlebarsjs.com/), so handlebars syntax can be used. The following variables are available in the templates:
|
||||
|
||||
- `{{version}}`: This will be replaced with the normalized version derived from the release branch. So for instance if the branch was `release/2.5` then the version value would be `2.5.0`.
|
||||
- `{{changelog}}`: This will be replaced with the changelog for the release (derived from the milestone).
|
||||
- `{{devNoteItems}}`: This contains a list of any pull requests requiring devnotes for the release.
|
||||
|
||||
|
||||
## Appendix: Versions
|
||||
|
||||
Woo Blocks follows the [same versioning process as WordPress](https://make.wordpress.org/core/handbook/about/release-cycle/version-numbering/) but with the following differences:
|
||||
|
||||
- Woo Blocks follows a scheduled release process (currently released every two weeks).
|
||||
- We might still refer to `3.2.1` as a "patch" release instead of a "minor" release. But functionally, it's the same concept as a WordPress "minor" release.
|
||||
|
||||
## Appendix: updating a specific file on WPORG
|
||||
|
||||
Sometimes, we need to update a single file in WordPress.org without wanting to do a full release, for example, updating the `readme.txt` versions or descriptions. In order to do that, refer to the _[Editing Existing Files](https://developer.wordpress.org/plugins/wordpress-org/how-to-use-subversion/#editing-existing-files)_ section of the Subversion guide in developer.wordpress.org or follow these steps:
|
||||
|
||||
1. Checkout the plugin repo:
|
||||
|
||||
```
|
||||
$ svn co "http://plugins.svn.wordpress.org/woo-gutenberg-products-block/"
|
||||
$ cd woo-gutenberg-products-block
|
||||
```
|
||||
|
||||
2. Modify the files you want to change in `trunk` or `tags/x.y.z`.
|
||||
|
||||
3. Check your changes with:
|
||||
|
||||
```
|
||||
$ svn stat
|
||||
$ svn diff
|
||||
```
|
||||
|
||||
4. Commit the changes to the server:
|
||||
|
||||
```
|
||||
$ svn ci -m "Updated readme.txt description"
|
||||
```
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
# Releases
|
||||
|
||||
This folder contains documentation on how to release and test new versions of the blocks plugin.
|
||||
|
||||
| Document | Description |
|
||||
| --------------------------------------------------------------------------- | -------------------------------------------------------------------- |
|
||||
| [Handling Releases](handling-releases.md) | How to build, deploy, and release new versions of the Blocks plugin. |
|
||||
| [WordPress Update Testing Checklist](wordpress-update-testing-checklist.md) | A checklist of things to test before a new release. |
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
# WordPress Update Testing Checklist
|
||||
|
||||
Wherever a new version of WordPress is released, or is due for release, there are
|
||||
a number of steps that developers should perform in order to ensure compatibility
|
||||
exists between WordPress, Gutenberg, and the Blocks plugin.
|
||||
|
||||
**Important:** Before testing, ensure you **disable** the **Gutenberg Feature Plugin** to ensure you're using the correct version of the Editor that is shipping with the new version of WordPress.
|
||||
|
||||
Additionally, ensure your test environment includes a mixture of existing blocks to ensure any existing blocks work after the update.
|
||||
|
||||
## Testing Checklist
|
||||
|
||||
1. Run through the [smoke testing checklist](../testing/smoke-testing.md) to ensure critical features are still functional.
|
||||
2. Verify the appearance of blocks on the frontend using the latest official theme. This includes new Twenty-X themes introduced every year.
|
||||
|
||||
## Updating `readme.txt`
|
||||
|
||||
Once testing is complete and any discovered issues are patched, update the `Tested up to: 5.3` version in readme.txt to match the minor version of WordPress. For example, `5.6`.
|
||||
|
||||
If a new fix release is needed to deal with any compatibility problems, any patches, and the readme.txt update, should be cherry picked into the release branch and deployed. See [Releasing Updates](readme.md).
|
||||
|
||||
If no changes are needed, and no fix releases are scheduled, you can use an SVN client to update the Stable Tag of the Blocks plugin in trunk (https://plugins.svn.wordpress.org/woo-gutenberg-products-block/trunk/). This will prevent the page on WordPress.org from warning users about incompatibilities.
|
||||
|
||||
Instructions for updating specific files on SVN can be [found in this doc](readme.md#appendix-updating-a-specific-file-on-wporg).
|
||||
Loading…
Reference in New Issue