Skip to content

Commit 943490c

Browse files
author
John Spellman
authored
Updates to CONTRIBUTING.md (#406)
1 parent 1c3e155 commit 943490c

File tree

9 files changed

+160
-144
lines changed

9 files changed

+160
-144
lines changed

.circleci/config.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -96,6 +96,7 @@ jobs:
9696
- restore_cache:
9797
keys:
9898
- test-phpunit-74-dependencies-{{ checksum "composer.json" }}
99+
- run: composer update
99100
- run: composer install -n --prefer-dist
100101
- save_cache:
101102
key: test-phpunit-74-dependencies-{{ checksum "composer.json" }}
@@ -136,6 +137,7 @@ jobs:
136137
- restore_cache:
137138
keys:
138139
- test-phpunit-74-dependencies-{{ checksum "composer.json" }}
140+
- run: composer update
139141
- run: composer install -n --prefer-dist
140142
- save_cache:
141143
key: test-phpunit-74-dependencies-{{ checksum "composer.json" }}

CONTRIBUTING.md

Lines changed: 27 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,13 @@ Pull requests and issues are welcome!
88

99
## Workflow
1010

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+
Development and releases are structured around two branches, `develop` and `master`. The `develop` branch is the default branch for the repository, and is the source and destination for feature branches.
12+
13+
We prefer to squash commits (i.e. avoid merge PRs) from a feature branch into `develop` when merging, and to include the PR # in the commit message. PRs to `develop` 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 `develop`.
14+
15+
`develop` should be stable and usable, though possibly a few commits ahead of the public release on wp.org.
16+
17+
The `master` branch matches the latest stable release deployed to [wp.org](wp.org).
1218

1319
## Testing
1420

@@ -25,13 +31,24 @@ Behat requires a Pantheon site with Redis enabled. Once you've created the site,
2531

2632
## Release Process
2733

28-
1. Starting from `develop`, cut a release branch named `release_X.Y.Z` containing your changes.
29-
1. Update plugin version in `README.md`, `readme.txt`, and `wp-redis.php`.
30-
1. Update the Changelog with the latest changes.
31-
1. Create a PR against the `master` branch.
32-
1. After all tests pass and you have received approval from a CODEOWNER (including resolving any merge conflicts), merge the PR into `master`.
33-
1. Pull `master` locally, create a new tag, and push up.
34+
1. From `develop`, checkout a new branch `release_X.Y.Z`.
35+
1. Make a release commit:
36+
* Drop the `-dev` from the version number in `README.md`, `readme.txt`, and `wp-redis.php`.
37+
* Update the "Latest" heading in the changelog to the new version number with the date
38+
* Commit these changes with the message `Release X.Y.Z`
39+
* Push the release branch up.
40+
1. Open a Pull Request to merge `release_X.Y.Z` into `master`. 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`.
41+
1. After all tests pass and you have received approval from a [CODEOWNER](./CODEOWNERS), merge the PR into `master`. "Rebase and merge" is preferred in this case. _Never_ squash to `master`.
42+
1. Pull `master` 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`).
3443
1. Confirm that the necessary assets are present in the newly created tag, and test on a WP install if desired.
35-
1. Create a [new release](https://github.com/pantheon-systems/wp-redis/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` into the body of the release and include a link to the closed issues if applicable.
36-
1. Wait for the [_Release wp-redis plugin to wp.org_ action](https://github.com/pantheon-systems/wp-redis/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.
37-
1. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/wp-redis/. This may take a few minutes.
44+
1. Create a [new release](https://github.com/pantheon-systems/wp-redis/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.
45+
1. Wait for the [_Release wp-redis plugin to wp.org_ action](https://github.com/pantheon-systems/wp-redis/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.
46+
1. Check WordPress.org: Ensure that the changes are live on [the plugin repository](https://wordpress.org/plugins/wp-redis/). This may take a few minutes.
47+
1. Following the release, prepare the next dev version with the following steps:
48+
* `git checkout develop`
49+
* `git rebase master`
50+
* 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`)
51+
* Add a new `** Latest **` heading to the changelog
52+
* `git add -A .`
53+
* `git commit -m "Prepare X.Y.X-dev"`
54+
* `git push origin develop`

README.md

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@
55
**Tags:** cache, plugin, redis
66
**Requires at least:** 3.0.1
77
**Tested up to:** 6.2
8-
**Stable tag:** 1.3.5
8+
**Stable tag:** 1.3.6-dev
99
**License:** GPLv2 or later
1010
**License URI:** http://www.gnu.org/licenses/gpl-2.0.html
1111

@@ -103,6 +103,10 @@ This declaration means use of `wp_cache_set( 'foo', 'bar', 'bad-actor' );` and `
103103
There's a known issue with WordPress `alloptions` cache design. Specifically, a race condition between two requests can cause the object cache to have stale values. If you think you might be impacted by this, [review this GitHub issue](https://github.com/pantheon-systems/wp-redis/issues/221) for links to more context, including a workaround.
104104

105105
## Changelog ##
106+
107+
### Latest ###
108+
* Update Composer dependencies [[#401](https://github.com/pantheon-systems/wp-redis/pull/394)]
109+
106110
### 1.3.5 (April 6, 2023) ###
107111
* Bump tested up to version to 6.2
108112
* Update Composer dependencies [[#394](https://github.com/pantheon-systems/wp-redis/pull/394)]

behat.yml

Lines changed: 0 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -7,15 +7,6 @@ default:
77
contexts:
88
- Behat\MinkExtension\Context\MinkContext
99
- PantheonSystems\PantheonWordPressUpstreamTests\Behat\AdminLogIn
10-
core:
11-
filters:
12-
tags: "~@upstreamonly"
13-
paths:
14-
- vendor/pantheon-systems/pantheon-wordpress-upstream-tests/features
15-
contexts:
16-
- Behat\MinkExtension\Context\MinkContext
17-
- PantheonSystems\PantheonWordPressUpstreamTests\Behat\AdminLogIn
18-
- PantheonSystems\PantheonWordPressUpstreamTests\Behat\ResponseHeader
1910
extensions:
2011
Behat\MinkExtension:
2112
# base_url set by ENV

bin/behat-prepare.sh

Lines changed: 6 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -30,6 +30,9 @@ set -ex
3030
terminus env:create $TERMINUS_SITE.dev $TERMINUS_ENV
3131
terminus env:wipe $SITE_ENV --yes
3232

33+
# Enable Redis
34+
terminus redis:enable $TERMINUS_SITE
35+
3336
###
3437
# Get all necessary environment details.
3538
###
@@ -87,7 +90,9 @@ terminus build:workflow:wait $TERMINUS_SITE.$TERMINUS_ENV
8790
{
8891
terminus wp $SITE_ENV -- core install --title=$TERMINUS_ENV-$TERMINUS_SITE --url=$PANTHEON_SITE_URL --admin_user=$WORDPRESS_ADMIN_USERNAME --admin_email=wp-redis@getpantheon.com --admin_password=$WORDPRESS_ADMIN_PASSWORD
8992
} &> /dev/null
90-
terminus wp $SITE_ENV -- cache flush
93+
94+
echo "Flush cache and setup environment..."
9195
terminus wp $SITE_ENV -- plugin activate wp-redis classic-editor
96+
terminus wp $SITE_ENV -- cache flush
9297
terminus wp $SITE_ENV -- theme activate twentyseventeen
9398
terminus wp $SITE_ENV -- rewrite structure '/%year%/%monthnum%/%day%/%postname%/'

composer.json

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@
1212
"behat/behat": "^3.1",
1313
"behat/mink-extension": "^2.2",
1414
"behat/mink-goutte-driver": "^1.2",
15-
"pantheon-systems/pantheon-wordpress-upstream-tests": "dev-master",
15+
"pantheon-systems/pantheon-wordpress-upstream-tests": "dev-fix-behat-upstream-tests",
1616
"wp-coding-standards/wpcs": "dev-develop as 2.3.1",
1717
"dealerdirect/phpcodesniffer-composer-installer": "^1.0.0",
1818
"phpunit/phpunit": "^9",

0 commit comments

Comments
 (0)