CSS naming convention docs (https://github.com/woocommerce/woocommerce-blocks/pull/1653)
* Move github specific MD files and config to .github directory. * Create security.md file * Add docs directory (and exclude from builds) * Add code of conduct MD * Move release docs to /docs directory * Add css guidelines * Feedback * Modifier example * Clarify package naming * descendant...
This commit is contained in:
Mike Jolley
GitHub
parent
db14accc64
commit
e1538395be
|
|
@ -15,3 +15,4 @@
|
|||
/package.json export-ignore
|
||||
/package-lock.json export-ignore
|
||||
/babel-config.js export-ignore
|
||||
/docs export-ignore
|
||||
|
|
|
|||
|
|
@ -0,0 +1,46 @@
|
|||
# Contributor Covenant Code of Conduct
|
||||
|
||||
## Our Pledge
|
||||
|
||||
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
|
||||
|
||||
## Our Standards
|
||||
|
||||
Examples of behavior that contributes to creating a positive environment include:
|
||||
|
||||
- Using welcoming and inclusive language
|
||||
- Being respectful of differing viewpoints and experiences
|
||||
- Gracefully accepting constructive criticism
|
||||
- Focusing on what is best for the community
|
||||
- Showing empathy towards other community members
|
||||
|
||||
Examples of unacceptable behavior by participants include:
|
||||
|
||||
- The use of sexualized language or imagery and unwelcome sexual attention or advances
|
||||
- Trolling, insulting/derogatory comments, and personal or political attacks
|
||||
- Public or private harassment
|
||||
- Publishing others' private information, such as a physical or electronic address, without explicit permission
|
||||
- Other conduct which could reasonably be considered inappropriate in a professional setting
|
||||
|
||||
## Our Responsibilities
|
||||
|
||||
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
|
||||
|
||||
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
|
||||
|
||||
## Scope
|
||||
|
||||
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project email address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
|
||||
|
||||
## Enforcement
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at support@woocommerce.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
|
||||
|
||||
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
|
||||
|
||||
## Attribution
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
|
||||
|
||||
[homepage]: http://contributor-covenant.org
|
||||
[version]: http://contributor-covenant.org/version/1/4/
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
# Reporting Security Issues
|
||||
|
||||
The WooCommerce team take security bugs seriously. We appreciate your efforts to responsibly disclose your findings, and will make every effort to acknowledge your contributions.
|
||||
|
||||
To report a security issue, please visit the [Automattic HackerOne](https://hackerone.com/automattic/) program.
|
||||
|
|
@ -1,155 +0,0 @@
|
|||
# Releases
|
||||
|
||||
This document outlines the process of releasing new versions of the blocks plugin.
|
||||
|
||||
## Prerequisites - what you need to release WooCommerce Blocks
|
||||
- You should be set up for development - for more info see [`CONTRIBUTING.md`](CONTRIBUTING.md).
|
||||
- Install & set up [GitHub hub](https://hub.github.com) tools.
|
||||
- Configure a GitHub token for release scripts to use.
|
||||
- https://github.com/settings/tokens
|
||||
- Select the following permissions:
|
||||
- `admin:org`
|
||||
- `public_repo`
|
||||
- `read:user`
|
||||
- Ensure your token is available to scripts, e.g. `export GH_API_TOKEN={YOUR-TOKEN}` or similar.
|
||||
- Get WPORG plugin svn commit access - ask a team member.
|
||||
|
||||
_Outcome_: __You are equipped to ship a release!__
|
||||
|
||||
## Release process
|
||||
### Lead-up to release
|
||||
#### Ensure release development is complete
|
||||
- For _major_ and _minor_ releases, we use ZenHub.
|
||||
- For _patch_ releases, we use GitHub milestones - [example](https://github.com/woocommerce/woocommerce-gutenberg-products-block/milestone/41).
|
||||
- Ensure all issues/PRs intended for this release are merged, closed and linked to release.
|
||||
- All PRs should have changelog entry, or `skip-changelog` tag.
|
||||
- Check with the team to confirm any outstanding or in progress work.
|
||||
|
||||
Note: changelog should be formatted like this in PR description. Note the preceding `> ` - this is required by changelog script.
|
||||
|
||||
```md
|
||||
### Changelog
|
||||
|
||||
> bug: Fix bug in Safari and other Webkit browsers that was causing the All Products block to show 0 results when resetting the sort value.
|
||||
```
|
||||
|
||||
_Outcome_: __Team is aware of release and in agreement about what fixes & features are included.__
|
||||
|
||||
#### Ensure release branch includes all relevant fixes
|
||||
- Make release branch (if needed).
|
||||
- For _major_ and _minor_ releases, create branch: `release/X.X`.
|
||||
- For _patch_ releases, the branch should already exist.
|
||||
- Ensure your local checkout is updated to the tip of the release branch.
|
||||
- For _patch_ releases, cherry pick relevant PRs into the release branch:
|
||||
- If PR is already labelled `status: cherry-picked 🍒` then continue to next PR.
|
||||
- Ideally, use GitHub Hub to cherry pick the PR - `hub am -3 {http://URL-TO-PR}`.
|
||||
- If there are serious conflicts or extensive differences between `master` and release branch, you may need to take more care:
|
||||
- Manually cherry pick individual commits using git - `git cherry-pick {COMMIT-HASH}`.
|
||||
- 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 🍒`.
|
||||
|
||||
_Outcome_: __Release branch has all relevant changes merged & pushed.__
|
||||
|
||||
### Prepare release
|
||||
#### Ensure release branch readme is up to date
|
||||
- Run changelog script `npm run changelog` to get changelog txt for readme. Changelog content will be output to screen by script.
|
||||
- The above script will automatically generate changelog entries from a milestone (you will be asked about the milestone name in the script).
|
||||
- If you want to pull changelog entries from a Zenhub release instead, use `npm run changelog:zenhub` and follow instructions.
|
||||
- Add changelog section for release, e.g. [`= 2.5.11 - 2020-01-20 =`](https://github.com/woocommerce/woocommerce-gutenberg-products-block/commit/74a41881bfa456a2167a52aaeb4871352255e328).
|
||||
- Copy-paste the changelog content into `readme.txt`.
|
||||
- Make any other changes to readme as needed - e.g. support versions changing, new blocks.
|
||||
- Push readme changes to release branch on origin repo.
|
||||
- Note: you can push your readme changes directly to branch – no need for a PR & review process.
|
||||
|
||||
_Outcome_: __Release branch has `readme.txt` is updated with release details.__
|
||||
|
||||
#### Build zip & smoke test
|
||||
- Ensure you are on the tip of the release branch, e.g. `git pull origin release/2.5`
|
||||
- Update dependencies – `npm ci`.
|
||||
- Run a production build - `npm run build`.
|
||||
- Run package script to get a zip to test `npm run package-plugin`.
|
||||
- Smoke test built release zip:
|
||||
- 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.
|
||||
|
||||
_Outcome_: __Confident that source code is ready for release: intended fixes are working correctly, no release blockers or build issues.__
|
||||
|
||||
### Release!
|
||||
#### Tag release on GitHub
|
||||
- Prepare tagged release on github `npm run deploy`.
|
||||
- Note: the script automatically updates version numbers (commits on your behalf).
|
||||
- Edit release, add changelog info to Github release notes.
|
||||
- Check release repo tag is correct - checkout, smoke test/confidence check.
|
||||
|
||||
_Outcomes_: __Version numbers updated in source code & developers can test tagged release.__
|
||||
|
||||
#### Release to WPORG
|
||||
- Run `npm run release`. This script clones a copy of the source code to your home folder, and outputs an `svn` command to push release up to WPORG.
|
||||
- Push release to WPORG using `svn`.
|
||||
- Run generated svn command to commit to WPORG svn repo.
|
||||
- The command should look like this: `cd /Users/{YOU}/blocks-deployment/woo-gutenberg-products-block-svn && svn ci -m "Release 2.5.11, see readme.txt for changelog."`
|
||||
- Commit should complete successfully with a message like `Committed revision 2231217.`.
|
||||
- Confirm that the WPORG release is updated and correct:
|
||||
- Changelog, `Version` & `Last updated` on [WPORG plugin page](https://wordpress.org/plugins/woo-gutenberg-products-block/).
|
||||
- Confirm svn tag is correct, e.g. [2.5.11](https://plugins.svn.wordpress.org/woo-gutenberg-products-block/tags/2.5.11/).
|
||||
- Confirm [WooCommerce.com plugin page](https://woocommerce.com/products/woocommerce-gutenberg-products-block/) is updated.
|
||||
- Download zip and smoke test.
|
||||
- Test updating plugin from previous version.
|
||||
|
||||
_Outcome_: __Customers can install/update via WPORG; WPORG plugin page is up to date__.
|
||||
|
||||
### After release
|
||||
#### Update `master` with release changes
|
||||
- Ensure changelog is up to date on master.
|
||||
- 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
|
||||
- For _patch_ releases, close the milestone in GitHub.
|
||||
- For _major_ & _minor_ releases - tbc
|
||||
|
||||
## Appendix: Versions
|
||||
We have _major_, _minor_ and _patch_ releases.
|
||||
|
||||
For example:
|
||||
|
||||
- version == 2.5.11
|
||||
- 2 == _major_ version; has breaking changes or major new features
|
||||
- 5 == _minor_ version; has new features
|
||||
- 11 == _patch_, aka point / revision / fix; has bug fixes and improvements to existing features
|
||||
- 2.0 is a _major_ release
|
||||
- 2.5 is a _minor_ release
|
||||
- 2.5.11 is a _patch_ release
|
||||
|
||||
There are some differences to our release process for each kind of release - these are detailed in the steps above.
|
||||
|
||||
## 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"
|
||||
```
|
||||
|
|
@ -41,6 +41,7 @@ copy_dest_files() {
|
|||
--exclude=bin/ \
|
||||
--exclude=node_modules/ \
|
||||
--exclude=tests/ \
|
||||
--exclude=docs/ \
|
||||
--exclude=phpcs.xml \
|
||||
--exclude=phpunit.xml.dist \
|
||||
--exclude=CODEOWNERS \
|
||||
|
|
|
|||
|
|
@ -52,6 +52,7 @@ copy_dest_files() {
|
|||
--exclude=bin/ \
|
||||
--exclude=node_modules/ \
|
||||
--exclude=tests/ \
|
||||
--exclude=docs/ \
|
||||
--exclude=phpcs.xml \
|
||||
--exclude=phpunit.xml.dist \
|
||||
--exclude=CODEOWNERS \
|
||||
|
|
|
|||
|
|
@ -0,0 +1,84 @@
|
|||
# Coding Guidelines
|
||||
|
||||
This living document serves to prescribe coding guidelines specific to the WooCommerce Blocks project. Base coding guidelines follow the [WordPress Coding Standards](https://make.wordpress.org/core/handbook/best-practices/coding-standards/) and [Gutenberg coding standards](https://developer.wordpress.org/block-editor/contributors/develop/coding-guidelines/).
|
||||
|
||||
The following sections outline additional patterns and conventions used in the Blocks project.
|
||||
|
||||
## CSS
|
||||
|
||||
### CSS Class Names
|
||||
|
||||
To avoid class name collisions, class names must adhere to the following guidelines, based on the [BEM methodology](https://en.bem.info/methodology/) and [Gutenberg coding standards](https://developer.wordpress.org/block-editor/contributors/develop/coding-guidelines/).
|
||||
|
||||
#### Prefixing
|
||||
|
||||
As a WordPress plugin, Blocks has to play nicely with other plugins and themes, and WordPress itself. To minimize potential conflicts, all classes should be prefixed with `.wc-block-`.
|
||||
|
||||
#### Naming
|
||||
|
||||
All class names assigned to an element must be prefixed with the following, each joined by a dash (`-`):
|
||||
|
||||
- The `wc-block` plugin prefix.
|
||||
- The name of the sub-package (where applicable, e.g. if there was a distributed sub-package called `components` living within the blocks plugin, the prefix would be `wc-block-components-`).
|
||||
- The name of the directory in which the component resides.
|
||||
|
||||
Any descendant of the component's root element must append a dash-delimited descriptor, separated from the base by two consecutive underscores `__`.
|
||||
|
||||
Example, `assets/base/components/checkbox-list` uses the class name: `wc-block-checkbox-list`.
|
||||
|
||||
A **root element** (or **Block** in BEM notation) is a standalone entity that is meaningful on its own. Whilst they can be nested and interact with each other, semantically they remain equal; there is no precedence or hierarchy.
|
||||
|
||||
Example: `wc-block-package-directory`
|
||||
|
||||
A **child element** (or **Element** in BEM notation) has no standalone meaning and is semantically tied to its block.
|
||||
|
||||
Example: `wc-block-package-directory__descriptor-foo-bar`
|
||||
|
||||
Finally, A **modifier** is a flag on an element which can be used to change appearance, behavior or state.
|
||||
|
||||
Example: `wc-block-package-directory__descriptor-foo-bar--state`
|
||||
|
||||
The **root element** is considered to be the highest ancestor element returned by the default export in the index.js. Notably, if your folder contains multiple files, each with their own default exported component, only the element rendered by that of index.js can be considered the root. All others should be treated as **descendants**.
|
||||
|
||||
Naming is not strictly tied to the DOM so it **doesn’t matter how many nested levels deep a descendant element is**. The naming convention is there to help you identify relationships with the root element.
|
||||
|
||||
**Nesting Example:**
|
||||
|
||||
- `wc-block-dropdown-selector` (Root Element/BEM Block)
|
||||
- ├── `wc-block-dropdown-selector__input` (Child Element/BEM Element)
|
||||
- ├── `wc-block-dropdown-selector__input--hidden` (Modifier)
|
||||
- └── `wc-block-dropdown-selector__placeholder` (Child Element/BEM Element)
|
||||
|
||||
### RTL Styles
|
||||
|
||||
Blocks uses the `webpack-rtl-plugin` package to generate styles for Right-to-Left languages. These are generated automatically.
|
||||
|
||||
To make adjustments to the generated RTL styles, for example, excluding certain rules from the RTL stylesheets, you should use the [control directives here](https://rtlcss.com/learn/usage-guide/control-directives/index.html).
|
||||
|
||||
For example, you can exclude individual lines:
|
||||
|
||||
```css
|
||||
.code {
|
||||
/*rtl:ignore*/
|
||||
direction: ltr;
|
||||
/*rtl:ignore*/
|
||||
text-align: left;
|
||||
}
|
||||
```
|
||||
|
||||
Or exclude blocks of CSS:
|
||||
|
||||
```css
|
||||
.code {
|
||||
/*rtl:begin:ignore*/
|
||||
direction: ltr;
|
||||
text-align: left;
|
||||
/*rtl:end:ignore*/
|
||||
}
|
||||
```
|
||||
|
||||
### SCSS File Naming Conventions for Blocks
|
||||
|
||||
The build process will split SCSS from within the blocks library directory into two separate CSS files when Webpack runs.
|
||||
|
||||
Styles placed in a `style.scss` file will be built into `build/style.css`, to load on the front end theme as well as in the editor. If you need additional styles specific to the block's display in the editor, add them to an `editor.scss`.
|
||||
|
|
@ -0,0 +1,170 @@
|
|||
# Releasing New Versions
|
||||
|
||||
This document outlines the process of releasing new versions of the blocks plugin.
|
||||
|
||||
## Prerequisites - what you need to release WooCommerce Blocks
|
||||
|
||||
- You should be set up for development - for more info see [`CONTRIBUTING.md`](CONTRIBUTING.md).
|
||||
- Install & set up [GitHub hub](https://hub.github.com) tools.
|
||||
- Configure a GitHub token for release scripts to use.
|
||||
- https://github.com/settings/tokens
|
||||
- Select the following permissions:
|
||||
- `admin:org`
|
||||
- `public_repo`
|
||||
- `read:user`
|
||||
- Ensure your token is available to scripts, e.g. `export GH_API_TOKEN={YOUR-TOKEN}` or similar.
|
||||
- Get WPORG plugin svn commit access - ask a team member.
|
||||
|
||||
_Outcome_: **You are equipped to ship a release!**
|
||||
|
||||
## Release process
|
||||
|
||||
### Lead-up to release
|
||||
|
||||
#### Ensure release development is complete
|
||||
|
||||
- For _major_ and _minor_ releases, we use ZenHub.
|
||||
- For _patch_ releases, we use GitHub milestones - [example](https://github.com/woocommerce/woocommerce-gutenberg-products-block/milestone/41).
|
||||
- Ensure all issues/PRs intended for this release are merged, closed and linked to release.
|
||||
- All PRs should have changelog entry, or `skip-changelog` tag.
|
||||
- Check with the team to confirm any outstanding or in progress work.
|
||||
|
||||
Note: changelog should be formatted like this in PR description. Note the preceding `>` - this is required by changelog script.
|
||||
|
||||
```md
|
||||
### Changelog
|
||||
|
||||
> bug: Fix bug in Safari and other Webkit browsers that was causing the All Products block to show 0 results when resetting the sort value.
|
||||
```
|
||||
|
||||
_Outcome_: **Team is aware of release and in agreement about what fixes & features are included.**
|
||||
|
||||
#### Ensure release branch includes all relevant fixes
|
||||
|
||||
- Make release branch (if needed).
|
||||
- For _major_ and _minor_ releases, create branch: `release/X.X`.
|
||||
- For _patch_ releases, the branch should already exist.
|
||||
- Ensure your local checkout is updated to the tip of the release branch.
|
||||
- For _patch_ releases, cherry pick relevant PRs into the release branch:
|
||||
- If PR is already labelled `status: cherry-picked 🍒` then continue to next PR.
|
||||
- Ideally, use GitHub Hub to cherry pick the PR - `hub am -3 {http://URL-TO-PR}`.
|
||||
- If there are serious conflicts or extensive differences between `master` and release branch, you may need to take more care:
|
||||
- Manually cherry pick individual commits using git - `git cherry-pick {COMMIT-HASH}`.
|
||||
- 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 🍒`.
|
||||
|
||||
_Outcome_: **Release branch has all relevant changes merged & pushed.**
|
||||
|
||||
### Prepare release
|
||||
|
||||
#### Ensure release branch readme is up to date
|
||||
|
||||
- Run changelog script `npm run changelog` to get changelog txt for readme. Changelog content will be output to screen by script.
|
||||
- The above script will automatically generate changelog entries from a milestone (you will be asked about the milestone name in the script).
|
||||
- If you want to pull changelog entries from a Zenhub release instead, use `npm run changelog:zenhub` and follow instructions.
|
||||
- Add changelog section for release, e.g. [`= 2.5.11 - 2020-01-20 =`](https://github.com/woocommerce/woocommerce-gutenberg-products-block/commit/74a41881bfa456a2167a52aaeb4871352255e328).
|
||||
- Copy-paste the changelog content into `readme.txt`.
|
||||
- Make any other changes to readme as needed - e.g. support versions changing, new blocks.
|
||||
- Push readme changes to release branch on origin repo.
|
||||
- Note: you can push your readme changes directly to branch – no need for a PR & review process.
|
||||
|
||||
_Outcome_: **Release branch has `readme.txt` is updated with release details.**
|
||||
|
||||
#### Build zip & smoke test
|
||||
|
||||
- Ensure you are on the tip of the release branch, e.g. `git pull origin release/2.5`
|
||||
- Update dependencies – `npm ci`.
|
||||
- Run a production build - `npm run build`.
|
||||
- Run package script to get a zip to test `npm run package-plugin`.
|
||||
- Smoke test built release zip:
|
||||
- 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.
|
||||
|
||||
_Outcome_: **Confident that source code is ready for release: intended fixes are working correctly, no release blockers or build issues.**
|
||||
|
||||
### Release!
|
||||
|
||||
#### Tag release on GitHub
|
||||
|
||||
- Prepare tagged release on github `npm run deploy`.
|
||||
- Note: the script automatically updates version numbers (commits on your behalf).
|
||||
- Edit release, add changelog info to Github release notes.
|
||||
- Check release repo tag is correct - checkout, smoke test/confidence check.
|
||||
|
||||
_Outcomes_: **Version numbers updated in source code & developers can test tagged release.**
|
||||
|
||||
#### Release to WPORG
|
||||
|
||||
- Run `npm run release`. This script clones a copy of the source code to your home folder, and outputs an `svn` command to push release up to WPORG.
|
||||
- Push release to WPORG using `svn`.
|
||||
- Run generated svn command to commit to WPORG svn repo.
|
||||
- The command should look like this: `cd /Users/{YOU}/blocks-deployment/woo-gutenberg-products-block-svn && svn ci -m "Release 2.5.11, see readme.txt for changelog."`
|
||||
- Commit should complete successfully with a message like `Committed revision 2231217.`.
|
||||
- Confirm that the WPORG release is updated and correct:
|
||||
- Changelog, `Version` & `Last updated` on [WPORG plugin page](https://wordpress.org/plugins/woo-gutenberg-products-block/).
|
||||
- Confirm svn tag is correct, e.g. [2.5.11](https://plugins.svn.wordpress.org/woo-gutenberg-products-block/tags/2.5.11/).
|
||||
- Confirm [WooCommerce.com plugin page](https://woocommerce.com/products/woocommerce-gutenberg-products-block/) is updated.
|
||||
- Download zip and smoke test.
|
||||
- Test updating plugin from previous version.
|
||||
|
||||
_Outcome_: **Customers can install/update via WPORG; WPORG plugin page is up to date**.
|
||||
|
||||
### After release
|
||||
|
||||
#### Update `master` with release changes
|
||||
|
||||
- Ensure changelog is up to date on master.
|
||||
- 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
|
||||
|
||||
- For _patch_ releases, close the milestone in GitHub.
|
||||
- For _major_ & _minor_ releases - tbc
|
||||
|
||||
## Appendix: Versions
|
||||
|
||||
We have _major_, _minor_ and _patch_ releases.
|
||||
|
||||
For example:
|
||||
|
||||
- version == 2.5.11
|
||||
- 2 == _major_ version; has breaking changes or major new features
|
||||
- 5 == _minor_ version; has new features
|
||||
- 11 == _patch_, aka point / revision / fix; has bug fixes and improvements to existing features
|
||||
- 2.0 is a _major_ release
|
||||
- 2.5 is a _minor_ release
|
||||
- 2.5.11 is a _patch_ release
|
||||
|
||||
There are some differences to our release process for each kind of release - these are detailed in the steps above.
|
||||
|
||||
## 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"
|
||||
```
|
||||
Loading…
Reference in New Issue