From 013c77bdd2eaba1836941d5a8660bc5e1f388049 Mon Sep 17 00:00:00 2001 From: Jeffrey Paul Date: Wed, 17 Feb 2021 11:36:57 -0600 Subject: [PATCH 1/2] update release instructions in CONTRIBUTING.md Co-Authored-By: Vasken Hauri --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f1dc25e362..1c4fef92af 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -31,11 +31,11 @@ The `develop` branch is the development branch which means it contains the next 1. If the new version requires a reindex, add its number to the `$reindex_versions` array in the `ElasticPress\Upgrades::check_reindex_needed()` method. If it is the case, remember to add that information to the Changelog listings in readme.txt and CHANGELOG.md. 1. Branch: Starting from `develop`, cut a release branch named `release/X.Y.Z` for your changes. 1. Version bump: Bump the version number in `elasticpress.php`, `package.json`, `readme.txt`, and any other relevant files if it does not already reflect the version being released. In `elasticpress.php` update both the plugin "Version:" property and the plugin `EP_VERSION` constant. -1. Changelog: Add/update the changelog in `CHANGELOG.md` and `readme.txt`, ensuring to link the release in the footer of `CHANGELOG.md`. +1. Changelog: Add/update the changelog in `CHANGELOG.md` and `readme.txt`, ensuring to link the [X.Y.Z] release reference in the footer of `CHANGELOG.md` (e.g., https://github.com/10up/ElasticPress/compare/X.Y.Z-1...X.Y.Z). 1. Props: Update `CREDITS.md` file with any new contributors, confirm maintainers are accurate. 1. Readme updates: Make any other readme changes as necessary. `README.md` is geared toward GitHub and `readme.txt` contains WordPress.org-specific content. The two are slightly different. 1. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in `.gitattributes`. -1. Merge: Make a non-fast-forward merge from your release branch to `develop` (or merge the pull request), then do the same for `develop` into `master` (`git checkout master && git merge --no-ff develop`). `master` contains the stable development version. +1. Merge: Merge the release branch/PR into `develop`, then make a non-fast-forward merge from `develop` into `master` (`git checkout master && git merge --no-ff develop`). `master` contains the stable development version. 1. Test: While still on the `master` branch, test for functionality locally. 1. Push: Push your `master` branch to GitHub (e.g. `git push origin master`). 1. Release: Create a [new release](https://github.com/10up/elasticpress/releases/new), naming the tag and the release with the new version number, and targeting the `master` branch. Paste the release changelog from `CHANGELOG.md` into the body of the release and include a link to the closed issues on the [milestone](https://github.com/10up/elasticpress/milestone/#?closed=1). From 18a240f9e63510e38a9b40232a2f5f0bdca27dbc Mon Sep 17 00:00:00 2001 From: Jeffrey Paul Date: Wed, 17 Feb 2021 12:11:30 -0600 Subject: [PATCH 2/2] add hotfix release instructions to CONTRIBUTING.md Co-Authored-By: Vasken Hauri --- CONTRIBUTING.md | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1c4fef92af..07b9eb6f3a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -28,12 +28,12 @@ The `develop` branch is the development branch which means it contains the next ## Release instructions -1. If the new version requires a reindex, add its number to the `$reindex_versions` array in the `ElasticPress\Upgrades::check_reindex_needed()` method. If it is the case, remember to add that information to the Changelog listings in readme.txt and CHANGELOG.md. +1. If the new version requires a reindex, add its number to the `$reindex_versions` array in the `ElasticPress\Upgrades::check_reindex_needed()` method. If it is the case, remember to add that information to the Changelog listings in `readme.txt` and `CHANGELOG.md`. 1. Branch: Starting from `develop`, cut a release branch named `release/X.Y.Z` for your changes. -1. Version bump: Bump the version number in `elasticpress.php`, `package.json`, `readme.txt`, and any other relevant files if it does not already reflect the version being released. In `elasticpress.php` update both the plugin "Version:" property and the plugin `EP_VERSION` constant. +1. Version bump: Bump the version number in `elasticpress.php`, `package.json`, `readme.txt`, and any other relevant files if it does not already reflect the version being released. In `elasticpress.php` update both the plugin "Version:" property and the plugin `EP_VERSION` constant. 1. Changelog: Add/update the changelog in `CHANGELOG.md` and `readme.txt`, ensuring to link the [X.Y.Z] release reference in the footer of `CHANGELOG.md` (e.g., https://github.com/10up/ElasticPress/compare/X.Y.Z-1...X.Y.Z). 1. Props: Update `CREDITS.md` file with any new contributors, confirm maintainers are accurate. -1. Readme updates: Make any other readme changes as necessary. `README.md` is geared toward GitHub and `readme.txt` contains WordPress.org-specific content. The two are slightly different. +1. Readme updates: Make any other readme changes as necessary. `README.md` is geared toward GitHub and `readme.txt` contains WordPress.org-specific content. The two are slightly different. 1. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in `.gitattributes`. 1. Merge: Merge the release branch/PR into `develop`, then make a non-fast-forward merge from `develop` into `master` (`git checkout master && git merge --no-ff develop`). `master` contains the stable development version. 1. Test: While still on the `master` branch, test for functionality locally. @@ -43,3 +43,24 @@ The `develop` branch is the development branch which means it contains the next 1. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/elasticpress/. This may take a few minutes. 1. Close milestone: Edit the [milestone](https://github.com/10up/elasticpress/milestone/#) with release date (in the `Due date (optional)` field) and link to GitHub release (in the `Description` field), then close the milestone. 1. Punt incomplete items: If any open issues or PRs which were milestoned for `X.Y.Z` do not make it into the release, update their milestone to `X.Y.Z+1`, `X.Y+1.0`, `X+1.0.0` or `Future Release`. + +## Hotfix release instructions + +There may be cases where we have an urgent/important fix that ideally gets into a release quickly without any other changes (e.g., a "hotfix") so as to reduce (1) the amount or testing before being confident in the release and (2) to reduce the chance of unintended side effects from the extraneous non-urgent/important changes. In cases where code has previously been merged into `develop` but that ideally is not part of a hotfix, the normal release instructions above will not suffice as they would release all code merged to `develop` alongside the intended urgent/important "hotfix" change(s). In case of needing to release a "hotfix" the following are the recommended steps to take. + +1. If the new version requires a reindex, add its number to the `$reindex_versions` array in the `ElasticPress\Upgrades::check_reindex_needed()` method. If it is the case, remember to add that information to the Changelog listings in `readme.txt` and `CHANGELOG.md`. +1. Branch: Starting from `master`, cut a hotfix release branch named `hotfix/X.Y.Z` for your hotfix change(s). +1. Version bump: Bump the version number in `elasticpress.php`, `package.json`, `readme.txt`, and any other relevant files if it does not already reflect the version being released. In `elasticpress.php` update both the plugin "Version:" property and the plugin `EP_VERSION` constant. +1. Changelog: Add/update the changelog in `CHANGELOG.md` and `readme.txt`, ensuring to link the [X.Y.Z] release reference in the footer of `CHANGELOG.md` (e.g., https://github.com/10up/ElasticPress/compare/X.Y.Z-1...X.Y.Z). +1. Props: Update `CREDITS.md` file with any new contributors, confirm maintainers are accurate. +1. Readme updates: Make any other readme changes as necessary. `README.md` is geared toward GitHub and `readme.txt` contains WordPress.org-specific content. The two are slightly different. +1. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in `.gitattributes`. +1. Merge: Merge the release branch/PR into `master`. `master` contains the stable development version. +1. Test: While still on the `master` branch, test for functionality locally. +1. Push: Push your `master` branch to GitHub (e.g. `git push origin master`). +1. Release: Create a [new release](https://github.com/10up/elasticpress/releases/new), naming the tag and the release with the new version number, and targeting the `master` branch. Paste the release changelog from `CHANGELOG.md` into the body of the release and include a link to the closed issues on the [milestone](https://github.com/10up/elasticpress/milestone/#?closed=1). +1. SVN: Wait for the [GitHub Action](https://github.com/10up/ElasticPress/actions?query=workflow%3A%22Deploy+to+WordPress.org%22) 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. +1. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/elasticpress/. This may take a few minutes. +1. Close milestone: Edit the [milestone](https://github.com/10up/elasticpress/milestone/#) with release date (in the `Due date (optional)` field) and link to GitHub release (in the `Description` field), then close the milestone. +1. Punt incomplete items: If any open issues or PRs which were milestoned for `X.Y.Z` do not make it into the hotfix release, update their milestone to `X.Y.Z+1`, `X.Y+1.0`, `X+1.0.0` or `Future Release`. +1. Apply hotfix changes to `develop`: Make a non-fast-forward merge from `master` into `develop` (`git checkout develop && git merge --no-ff master`) to ensure your hotfix change(s) are in sync with active development. \ No newline at end of file