We're updating the issue view to help you get more done. 

Hotfix branches for support branches


The current branching model only has a support branch where both dev-commits happen as well has an increase of the build metadata. The gitflow-documentation at https://gitversion.readthedocs.io/en/latest/git-branching-strategies/gitflow-examples/ shows how to solve this:

On the support branch, we create a hotfix branch ("hotfix/v2.1.1"). The hotfix branch follows the same logic as the develop branch:

  • The build metadata is updated to reflect the next (patch) version and has corresponding development pre-release information.

  • Pre-release branches for alpha and beta are created from and integrated back into the hotfix branch, same as on the develop branch. The tag is set on the pre-release branch.

  • Release branch is created from the hotfix branch and integrated back into both the hotfix branch and the support branch. The non-prerelease tag is set on the support branch.

  • When the release is performed, the hotfix branch is deleted and a new hotfix branch is created for the next patch version.

  • When creating a master merge, the script automatically creates a support branch and the first hotfix branch. (TODO: Create an extra Jira Ticket)

Note: We will continue to not use hotfix branches for the master, to make it easier to track the changes in a support branch and because there might be merge conflicts when trying to merge the master-hotfix into the develop as well.

 Prerelease/Release and Hotfix Branches should be deleted locally after the branches are pushed

New constraints:

  • prerelease/release branches on support branches are not allowed/offered by the script

  • prerelease/release branches on hotfix branches are allowed/offered by the script

We should do a concept presentation before implementation starts to make sure all the details are understood and up to date.


Stefan Ilic


Michael Ketting




Fix versions