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:
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
- As soon as a minor release is finalized (e.g we released
1.0.0) we tag it on
- 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.xwill go here.
- The master branch is then where
1.1.xnew minor release development begins, and the POM version is set at
1.1.0is 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.