cactus

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.

logo_cactus

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.

Like this post? Share on: TwitterFacebookEmail


Antoine Dauptain is a research scientist focused on computer science and engineering topics for HPC.

Keep Reading


Published

Category

Pitch

Tags

Stay in Touch