master branch contains the public and stable, currently released version of the plugin. At the end of a release cycle, release branches are merged into the master branch. The
master branch should generally not be committed to, except by the developer in charge of releasing the plugin.
NOTE: if you need to test something against the currently released version of the plugin, a simple way to switch to that version is by checking out the
master branch. Just be sure to switch back to your working branch before you make any commits!
We organize our releases on release branches by team. Release branches follow this naming scheme:
- T = team initial
- Y = 2 digit year
- N = release name (thematic, alphabetical name)
- H = hotfix number
An example release from the 2nd release from Blue Team in 2021 would be:
release/B21.bagel and a hotifx for that release would be:
NOTE: The following instructions are for internal use only, if you’re sending a pull request, it’ll already be in its own branch.
The naming convention for new branches should be as such
When working on features that require multiple devs, multiple sprints, or parts built in chunks, we consider this a major feature. Major features require “Bucket branches”–specifically, branches named
bucket/feature-name. These bucket branches should be decided upon by the team, as all PRs related to that feature will be pull requested into that bucket branch.
Major features are segregated into bucket branches to allow for focused QA effort before being merged into a release branch, as major features carry the most risk of being delayed.
Minor features can be developed using branches named
feature/TICKET-name-of-feature and pull requested directly into release branches.
Fixes can be developed using branches named
fix/TICKET-name-of-fix and pull requested directly into release branches.
Tweaks–or small changes to functionality with low impact–can be developed using branches named
feature/TICKET-name-of-fix and pull requested directly into release branches.