You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+28-11Lines changed: 28 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,13 +8,19 @@ Please feel free to file issues there. Pull requests are also welcome!
8
8
9
9
## Workflow
10
10
11
-
The `develop` branch is the development branch which means it contains the next version to be released. `master` contains the corresponding stable development version. Always work on the `develop` branch and open up PRs against `develop`.
11
+
The `main` branch is the development branch which means it contains the next version to be released. `release` contains the corresponding stable development version. Always work on the `main` branch and open up PRs against `main`.
12
+
13
+
We prefer to squash commits (i.e. avoid merge PRs) from a feature branch into `main` when merging, and to include the PR # in the commit message. PRs to `main` should also include any relevent updates to the changelog in readme.txt. For example, if a feature constitutes a minor or major version bump, that version update should be discussed and made as part of approving and merging the feature into `main`.
14
+
15
+
`main` should be stable and usable, though possibly a few commits ahead of the public release on wp.org.
16
+
17
+
The `release` branch matches the latest stable release deployed to [wp.org](wp.org).
12
18
13
19
## Testing
14
20
15
21
You may notice there are three sets of tests running:
16
22
17
-
*[PHPCS](https://github.com/squizlabs/PHP_CodeSniffer) to detect violations of `wp-coding-standards/wpcs` coding standards.
23
+
*[PHPCS](https://github.com/squizlabs/PHP_CodeSniffer) to detect violations of [Pantheon WP Coding Standards](https://github.com/pantheon-systems/Pantheon-WP-Coding-Standards).
18
24
*[PHPUnit](https://phpunit.de/) test suite.
19
25
*[Behat](http://behat.org/) test suite against a Pantheon site, to ensure the plugin's compatibility with the Pantheon platform.
20
26
@@ -28,13 +34,24 @@ Note that dependencies are installed via Composer and the `vendor` directory is
28
34
29
35
## Release Process
30
36
31
-
1. Starting from `develop`, cut a release branch named `release_X.Y.Z` containing your changes.
32
-
1. Update plugin version in `package.json`, `README.md`, `readme.txt`, and `pantheon-hud.php`.
33
-
1. Update the Changelog with the latest changes.
34
-
1. Create a PR against the `master` branch.
35
-
1. After all tests pass and you have received approval from a CODEOWNER (including resolving any merge conflicts), merge the PR into `master`.
36
-
1. Pull `master` locally, create a new tag, and push up.
37
+
1. From `main`, checkout a new branch `release_X.Y.Z`.
38
+
1. Make a release commit:
39
+
* Drop the `-dev` from the version number in `package.json`, `README.md`, `readme.txt`, and `pantheon-hud.php`.
40
+
* Update the "X.Y.Z-dev" heading in the changelog to the new version number with the date
41
+
* Commit these changes with the message `Release X.Y.Z`
42
+
* Push the release branch up.
43
+
1. Open a Pull Request to merge `release_X.Y.Z` into `release`. Your PR should consist of all commits to `main` since the last release, and one commit to update the version number. The PR name should also be `Release X.Y.Z`.
44
+
1. After all tests pass and you have received approval from a CODEOWNER (including resolving any merge conflicts), merge the PR into `release`. Use a "merge" commit, do no not rebase or squash.
45
+
1. Pull `release` locally, create a new tag, and push up.
37
46
1. Confirm that the necessary assets are present in the newly created tag, and test on a WP install if desired.
38
-
1. Create a [new release](https://github.com/pantheon-systems/pantheon-hud/releases/new), naming the release with the new version number, and targeting the tag created in the previous step. Paste the release changelog from `CHANGELOG.md` into the body of the release and include a link to the closed issues if applicable.
39
-
1. Wait for the [_Release pantheon-hud plugin to wp.org_ action](https://github.com/pantheon-systems/pantheon-hud/actions/workflows/wordpress-plugin-deploy.yml) to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
40
-
1. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/pantheon-hud/. This may take a few minutes.
47
+
1. Create a [new release](https://github.com/pantheon-systems/pantheon-hud/releases/new) using the tag created in the previous steps, naming the release with the new version number, and targeting the tag created in the previous step. Paste the release changelog from the `Changelog` section of [the readme](readme.txt) into the body of the release, including the links to the closed issues if applicable.
48
+
1. Wait for the [_Release pantheon-hud plugin to wp.org_ action](https://github.com/pantheon-systems/pantheon-hud/actions/workflows/wordpress-plugin-deploy.yml) to finish deploying to the WordPress.org plugin repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
49
+
1. Check WordPress.org: Ensure that the changes are live on [the plugin repository](https://wordpress.org/plugins/pantheon-hud/). This may take a few minutes.
50
+
1. Following the release, prepare the next dev version with the following steps:
51
+
*`git checkout develop`
52
+
*`git rebase release`
53
+
* Update the version number in all locations, incrementing the version by one patch version, and add the `-dev` flag (e.g. after releasing `1.2.3`, the new verison will be `1.2.4-dev`)
54
+
* Add a new `** X.Y.Z-dev **` heading to the changelog where `X.Y.Z-dev` is the new patch version.
This plugin provides situational awareness of the Pantheon plaform from within your WordPress dashboard. It's helpful to be reminded what environment you're in, as well as providing quick links to get back to Pantheon's dashboard, or to interface with your WordPress installation via the command line.
@@ -35,13 +36,19 @@ By default, the Pantheon HUD appears for logged-in users with the `manage_option
35
36
## Screenshots ##
36
37
37
38
### 1. Pantheon HUD is present in the WordPress toolbar. On hover, it displays environmental details and helpful links. ###
38
-

39
+

0 commit comments