Move branch workflow from develop and master to default and release

.circleci/config.yml

@@ -16,7 +16,7 @@ workflows:
           filters:
             branches:
               only:
-                - master
+                - release
     jobs:
       - test-behat
 jobs:

.github/dependabot.yml

@@ -6,7 +6,7 @@ updates:
     interval: weekly
     timezone: America/Los_Angeles
     day: tuesday
-  target-branch: "develop"
+  target-branch: "default"
   open-pull-requests-limit: 99
   ignore:
   - dependency-name: phpunit/phpunit
@@ -16,12 +16,4 @@ updates:
   - dependency-name: phpunit/phpunit
     versions:
     - ">= 9.a"
-    - "< 10"
-- package-ecosystem: npm
-  directory: "/"
-  schedule:
-    interval: weekly
-    timezone: America/Los_Angeles
-    day: tuesday
-  target-branch: "develop"
-  open-pull-requests-limit: 99
+    - "< 10"

CONTRIBUTING.md

@@ -8,13 +8,13 @@ Pull requests and issues are welcome!
 
 ## Workflow
 
-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.
+Development and releases are structured around two branches, `default` and `release`. The `default` branch is the default branch for the repository, and is the source and destination for feature branches.
 
-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`.
+We prefer to squash commits (i.e. avoid merge PRs) from a feature branch into `default` when merging, and to include the PR # in the commit message. PRs to `default` 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 `default`.
 
-`develop` should be stable and usable, though possibly a few commits ahead of the public release on wp.org.
+`default` should be stable and usable, though possibly a few commits ahead of the public release on wp.org.
 
-The `master` branch matches the latest stable release deployed to [wp.org](wp.org).
+The `release` branch matches the latest stable release deployed to [wp.org](wp.org).
 
 ## Testing
 
@@ -27,19 +27,21 @@ Both of these test suites can be run locally, with a varying amount of setup.
 
 PHPUnit requires the [WordPress PHPUnit test suite](https://make.wordpress.org/core/handbook/testing/automated-testing/phpunit/), and access to a database with name `wordpress_test`. If you haven't already configured the test suite locally, you can run `bash bin/install-wp-tests.sh wordpress_test root '' localhost`. You'll also need to enable Redis and the PHPRedis extension in order to run the test suite against Redis.
 
-Behat requires a Pantheon site with Redis enabled. Once you've created the site, you'll need [install Terminus](https://github.com/pantheon-systems/terminus#installation), and set the `TERMINUS_TOKEN`, `TERMINUS_SITE`, and `TERMINUS_ENV` environment variables. Then, you can run `./bin/behat-prepare.sh` to prepare the site for the test suite.
+The behat tests require a Pantheon site with Redis enabled. Once you've created the site, you'll need [install Terminus](https://github.com/pantheon-systems/terminus#installation), and set the `TERMINUS_TOKEN`, `TERMINUS_SITE`, and `TERMINUS_ENV` environment variables. Then, you can run `./bin/behat-prepare.sh` to prepare the site for the test suite.
 
 ## Release Process
 
-1. From `develop`, checkout a new branch `release_X.Y.Z`.
+1. From `default`, 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 `wp-redis.php`.
     * Update the "Latest" 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 `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`.
-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`.
-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`).
+1. Open a Pull Request to merge `release_X.Y.Z` into `release`. Your PR should consist of all commits to `default` 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 `release`. "Rebase and merge" is preferred in this case. _Never_ squash to `release`.
+1. Pull `release` 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`).
+    * `git tag X.Y.Z`
+    * `git push --tags`
 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-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.
 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.

README.md

@@ -13,7 +13,7 @@ Back your WP Object Cache with Redis, a high-performance in-memory storage backe
 
 ## Description ##
 
-[![CircleCI](https://circleci.com/gh/pantheon-systems/wp-redis/tree/master.svg?style=svg)](https://circleci.com/gh/pantheon-systems/wp-redis/tree/master)
+[![CircleCI](https://circleci.com/gh/pantheon-systems/wp-redis/tree/release.svg?style=svg)](https://circleci.com/gh/pantheon-systems/wp-redis/tree/release)
 
 For sites concerned with high traffic, speed for logged-in users, or dynamic pageloads, a high-speed and persistent object cache is a must. You also need something that can scale across multiple instances of your application, so using local file caches or APC are out.
 
@@ -78,7 +78,7 @@ Use `wp help redis <command>` to learn more about each command.
 
 ## Contributing ##
 
-See [CONTRIBUTING.md](https://github.com/pantheon-systems/wp-redis/blob/master/CONTRIBUTING.md) for information on contributing.
+See [CONTRIBUTING.md](https://github.com/pantheon-systems/wp-redis/blob/default/CONTRIBUTING.md) for information on contributing.
 
 ## Frequently Asked Questions ##