Applying a hotfix to develop in GitVersion 6

[dry-lenses]

Hey, another one from me - I wanted to ask what is the recommended way with GitVersion 6 and standard GitFlow configuration to apply a change from a hotfix branch to the develop branch? Of course first the hotfix branch gets merged to main, but usually the fix needs to make its way to develop as well. In GitVersion 5, it was possible to just merge the same hotfix branch to develop. In version 6, merging a hotfix branch (or even a release for that matter) to develop results in the commit counter in -alpha.N being reset. So, what is the recommended way? Using a feature/ branch? Merging main into develop? I looked at the examples but this is not mentioned there.

[HHobeck]

Can you give a concrete example? The reason why the pre-release version number will be reset is because of an tag and a main version release.

[dry-lenses]

So now I wanted to reproduce it with a completely fresh repo and I'm struggling to do so. What I observed in the other repo (which is also relatively new, I started it specifically to test out GitVersion 6 couple of weeks ago) was:

• version on develop was 0.5.0-alpha.7
• I merged hotfix/0.4.1 to both main and develop
• the version on develop decreased to 0.5.0-alpha.3

the log said:

INFO [25-04-15 14:42:52:54] -< Begin: Using continuous delivery workflow to calculate the incremented version. >-
INFO [25-04-15 14:42:52:54] 3 commits found between '9ce9705' - Revert "..." and '38a06fc' - Merge pull request #23 from my-company-name/hotfix/0.4.1
INFO [25-04-15 14:42:52:54] -< End: Using continuous delivery workflow to calculate the incremented version. (Took: 2.06ms) >-

So it started counting commits again from the merge of the hotfix branch that has just happened.

The config on develop at this moment was:

branches:
   release:
     mode: ContinuousDelivery
   hotfix:
     mode: ContinuousDelivery

Not sure why I can't reproduce it now in a clean repo, I'll continue to try and let you know if I do.

[HHobeck]

I would recommend explicitly specifying the base workflow template.

From scratch:

workflow: ''
..

or extending from git flow workflow:

workflow: GitFlow/v1
..

[HHobeck]

If you merge a hotfix or release branch the version number (in the branch name) will be used in the MergeMessageVersionStrategy class to determine the next version number. This merge commit will be used as the base version source which means a reset of the pre-release number might be possible and correct.

Edit: The behavior can be controlled on branch configuration layer with the track-merge-message property (see https://gitversion.net/docs/reference/configuration):

track-merge-message
This property is a branch related property and gives the user the possibility to control the behavior of whether the merge commit message will be interpreted as a next version or not. Consider we have a main branch and a release/1.0.0 branch and merge changes from release/1.0.0 to the main branch. If track-merge-message is set to true then the next version will be 1.0.0 otherwise 0.0.1.