From 305b547f2f262251743b93a8a417db14ffeb146c Mon Sep 17 00:00:00 2001 From: Phil Tyler Date: Tue, 10 Oct 2023 10:33:17 -0700 Subject: [PATCH] Update CONTRIBUTING.md --- CONTRIBUTING.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a8556e24..11c774fe 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -34,11 +34,11 @@ The `main` branch matches the latest stable release deployed to [wp.org](wp.org) 1. From `develop`, checkout a new branch `release_X.Y.Z`. 1. Make a release commit: * Drop the `-dev` from the version number in `README.md`, `readme.txt`, and `pantheon-sessions.php`. - * Update the "Latest" heading in the changelog to the new version number with the date + * Update the "X.Y.Z-dev" heading in the changelog to the new version number with the date * Commit these changes with the message `Release X.Y.Z` * Push the release branch up. 1. Open a Pull Request to merge `release_X.Y.Z` into `main`. Your PR should consist of all commits to `develop` since the last release, and one commit to update the version number. The PR name should also be `Release X.Y.Z`. -1. After all tests pass and you have received approval from a [CODEOWNER](./CODEOWNERS), merge the PR into `main`. "Rebase and merge" is preferred in this case. _Never_ squash to `main`. +1. After all tests pass and you have received approval from a [CODEOWNER](./CODEOWNERS), merge the PR into `main`. A merge commit is preferred in this case. A rebase or squash to `main` otherwise necessitates a force push to `develop` at a later step. 1. Pull `main` locally, create a new tag (based on version number from previous steps), and push up. The tag should _only_ be the version number. It _should not_ be prefixed `v` (i.e. `X.Y.Z`, not `vX.Y.X`). 1. Confirm that the necessary assets are present in the newly created tag, and test on a WP install if desired. 1. Create a [new release](https://github.com/pantheon-systems/wp-native-php-sessions/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,7 +48,7 @@ The `main` branch matches the latest stable release deployed to [wp.org](wp.org) * `git checkout develop` * `git rebase main` * 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`) - * Add a new `** Latest **` heading to the changelog + * Add a new ** X.Y.Z-dev ** heading to the changelog where X.Y.Z-dev is the new patch version. * `git add -A .` * `git commit -m "Prepare X.Y.X-dev"` * `git push origin develop`