Uyuni Salt Flat, Bolivia, Photo Pierre Ricadat
How do we stick to a strict semantic versioning and up-to-date changelog during the branching process ?
Here is the COOP custom version of the Cactus Branching Model.
Branching models shape the way people collaborate on a development. You can read first this introduction to Four branching models.
The COOP cactus model is a one-trunk model similar to the Cactus Model of the previous post, sometime referred as the Anti GitFlow model We needed to add precisions on how and when we should tag , branch , ship our products.
This one-trunk model is adapted to our medium-sized projects, roughly:
- 100-5000 lines of core code
- up to 3 simultaneous developers
- discontinuous development : activity can drop to zero during years, until an emergency task happens.
For smaller projects, we sometime use a simpler flow without the release branches. We try to avoid bigger projects by splitting them into single-purpose smaller pieces.
Commit procedures
Unreleased developments
- Create a new feature branch from master [eg. version 2.2.0a0] and checkout on it.
- Make your changes [Addition, modification, withdrawal] respecting Open-Closed principle.
- If possible, add or modify tests for your developments.
- Commit your changes.
When your developments are done :
- Check tests are running correctly.
- Explain your modifications in the CHANGELOG.md in the convenient block of the “Unreleased” paragraph, and commit.
- Merge master branch into your feature branch.
- Resolve merge conflicts if necessary.
- Recheck tests are running correctly.
- Merge your feature branch into the master branch.
- Delete your branch.
These developments will figure on next release [eg. version 2.2.0].
Bug fix on released branch
- Checkout on target released branch [eg. version 2.1.0].
- Make your changes.
- Explain your modifications in the CHANGELOG.md in the convenient block of the corresponding release paragraph.
- Increment version in setup.py [eg. to version 2.1.1].
- Commit your changes.
- Create a tag with incremented version name [eg. 2.1.1].
- Upload new tag on pypi if necessary.
Release branch creation procedure
When all developments are operational, you can generate a stable release branch.\ From a master branch of version 2.2.0a0 :
- Replace “## Unreleased” title by “## [2.2.0] YYYY / MM / DD” in the CHANGELOG.md and commit.
- From master branch [version 2.2.0a0] create a new branch 2.2 and checkout on it.
- Modify setup.py version to 2.2.0 and commit.
- Create a tag 2.2.0 on the last commit.
- Define branch 2.2 as default branch on your Git software (Github, Nitrox, …)
- Checkout back on master branch. Modify setup.py version to 2.3.0a0, add a new “## Unreleased” paragraph in CHANGELOG.md and commit.
Read more
Read more about the cactus model and others git models on the Git Workflows Warehouse.