Starting with Bolt 2, the branching model will be inspired from Git Ship, a simplified Git Flow that focuses on shipping code and minimizing unnecessary branches and merges.

Legend

• Vertical Dotted Line: Conceptual lane, no practical relationship
• Horizontal Dashed Line: Conceptual milestone, no practical break
• Solid Circles: Commits with developer changes
• Dashed Circles: Merge commits
• Solid Bubbles: Mandatory tags / branch name
• Dashed Bubbles: Optional tags
• Grey Bubbles: Comments / Examples

Notes

• There is no develop branch. The working tree is considered to be the latest release. All changes should be either features (in a feature branch), fixes (in a release branch), or versioning (in the master branch).
• Release branches are created per MINOR version number and are the active working tree until a new MINOR version is started. This allows the adding PATCH fixes to them with a minimal number of branches or merges. Release branches stay alive indefinitely to easy allow for backtracking to a previous release for regression checks.
• While a release branch is not feature complete, it can be distributed as an ALPHA version and must be tagged upon doing so.
• When a release branch feature complete, it can be distributed as a BETA version and must be tagged upon doing so.
• Before distributing any release, even preview releases, a commit containing the in-plugin versioning and changelog must be created on the release branch itself. This commit is the one that must be tagged and is considered to be shippable.
• Merge back to the master branch after a final tagged versioning commit has been created on the release branch. Do not tag the merged master commit.