Skip to content

Update CONTRIBUTING.md #319

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jazzsequence wants to merge 1 commit into from
Closed

Update CONTRIBUTING.md #319

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,11 +21,11 @@ Behat requires a Pantheon site. Once you've created the site, you'll need [insta

## Workflow

Development and releases are structured around two branches, `main` and `release`. The `main` branch is the source and destination for feature branches.
Development and releases are structured around two branches, `develop` and `release`. The `develop` branch is the source and destination for feature branches.

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. 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`.
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. 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`.

`main` should be stable and usable, though will be few commits ahead of the public release on wp.org.
`develop` should be stable and usable, though will be few commits ahead of the public release on wp.org.

The `release` branch matches the latest stable release deployed to [wp.org](wp.org).

Expand All @@ -39,10 +39,10 @@ The `release` branch matches the latest stable release deployed to [wp.org](wp.o
1. Wait for the [_Release wp-native-php-sessions plugin to wp.org_ action](https://github.com/pantheon-systems/wp-native-php-sessions/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.
1. Check WordPress.org: Ensure that the changes are live on [the plugin repository](https://wordpress.org/plugins/native-php-sessions/). This may take a few minutes.
1. Following the release, prepare the next dev version with the following steps:
* `git checkout main`
* `git pull origin main`
* `git checkout release`
* `git pull origin release`
* `git checkout develop`
* `git rebase main`
* `git rebase release`
* 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 `** X.Y.X-dev **` heading to the changelog
* `git add -A .`
Expand Down