A Better Branching Model for RESTHeart (Archived)

Our blog has moved to Medium


A Better Branching Model for RESTHeart

08 October 2015  • SoftInstigate Team
Categories: en, technology  • Tags: restheart

RESTHeart’s GitHub repo so far has been organized mimicking the Gitflow process, but we think this is not anymore a best practice for products.

Before reaching version 1.0.0 we had a “develop” branch with SNAPSHOT and a “master” for final releases. Now we have reached 1.0.0 and we need to support a more functional organization of code to support future versions and their long term maintenance.

New branching policy

There are two outstanding public examples to follow:

  1. Spring Boot
  2. Undertow

These projects have one “master” where all the new code is committed (unreleased versions) while released versions are tagged on master and then maintained in their own branches (named 1.0.x, 1.1.x, 1.2.x, ….).


  1. As soon as a minor release is finalized (e.g we released 1.0.0) we tag it on master
  2. Then we create the related support branch, in this case named 1.0.x, with version set to 1.0.1-SNAPSHOT. Hotfixes for 1.0.x will go here.
  3. The master branch is then where 1.1.x new minor release development begins, and the POM version is set at 1.1.0-SNAPSHOT
  4. When 1.1.0 is final, the process starts again from 1.

So, starting from today, the master branch is the primary one, so don’t use the develop branch anymore.

Master is now set at 1.1.0-SNAPSHOT, please check it out if you need to work with SNAPSHOT releases, while hotfixes for 1.0.0 will go into the dedicated 1.0.x branch only.

Releases and their version numbers will strictly follow a Semantic Versioning policy.