If you want to contribute, this is an overview of how we manage the project.
Workflow on GitHub¶
All usually starts with a GitHub issue which is labeled and put to a certain milestone. GitHub projects are used to more granularly track issue states.
Pull requests implement the functionality. We use the GitHub flow:
Guidelines we follow:
- Branches are commonly named
123references an issue.
- We never force-push or otherwise amend published commits, for example, we don't rebase or squash commits. Work-in-progress commits are absolutely fine.
- It's often useful to open a pull request early so that it can be discussed.
- When the development is done, we try to update the PR description so that it's a good overview of the change for anyone reading it in the future.
It evolves over time, it's best to find the most recent issue with the
release label and start from there. General steps involve:
- Generate a list of pull requests between the latest released version and
masterby running e.g.
npm run changelog -- 4.0..master, see
- Review the pull requests, possibly update their titles, add 'noteworthy' label to those that should be highlighted, etc.
- Write release notes.
- Tag a version, prepare a build. (The WP plugin version is automatically inferred from a Git tag.)
- Publish a GitHub release.
- Announce the release.
We use semver-like versioning with several differences:
- If there's no patch version yet, we simply call it
- We bump major versions frequently and don't use minor versions too much.
A sequence of releases might look like this:
Writing release notes¶
Release notes are primarily written in
docs/content/en/release-notes and published here. They are also copied to GitHub releases with some slight formatting modifications.