How can I tell Gitversion how to parse version from branch name?

Question

My build team currently has setup our branch names to follow convention Feature_*, Bugfix_*, Hotfix_*, Release_*. Doing a google search I see typical naming conventions use all lowercase with either a dash ('-') or folder ('/') marker for each of these branch types rather than the underscore ('_') delimiter I have here. For most part I can use the regex expression in the Gitversion.yml file so gitversion can properly identify the branch type.

However, there is issue with Release branches and ability for GitVersion tool to pick up the version # from the branch name. It appears here that Gitversion tool can only do this if naming convention matches release/<version> or release-<version>. But if I instead use Release_<version> it will not parse the branch name to get new version #. I have asked build team if we could switch the naming convention here, but they balk at changing the naming convention as could affect many other repos and their Jenkins configurations.

Is there any way for me to let the Gitversion tool know that my naming convention is Release_<version> and pare the version # accordingly - whether it be with Gitversion.yml or other means?

I have modified the GitVersion.yml with regex to identify the release branch and this works correctly in identifying what is a release branch. But it does not parse suggested version from branch name.

My GitVersion.yml

mode: ContinuousDelivery
branches:
  master:
    regex: master
    tag: ''
    is-release-branch: false
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    tracks-release-branches: false
  release:
    regex: Release_
    tag: ''
    is-release-branch: true
    is-mainline: true
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    tracks-release-branches: false
    source-branches: ['develop']
  feature:
    regex: Feature_
    is-release-branch: false
    prevent-increment-of-merged-branch-version: false
    track-merge-target: false
    tracks-release-branches: false
  pull-request:
    regex: (pull|pull\-requests|pr)[/-]
    is-release-branch: false
    prevent-increment-of-merged-branch-version: false
    track-merge-target: false
    tracks-release-branches: false
  hotfix:
    regex: Hotfix_
    is-release-branch: false
    prevent-increment-of-merged-branch-version: false
    track-merge-target: false
    tracks-release-branches: false
  develop:
    regex: develop
    mode: ContinuousDeployment
    is-release-branch: false
    prevent-increment-of-merged-branch-version: false
    track-merge-target: true
    tracks-release-branches: true
ignore:
  sha: []
merge-message-formats: {}

I expect if I provide a branch name of Release_0.99.1 I should get a version # of 0.99.1.Instead getting a version # of 0.1.0.

Answer 1

The code in GitVersion does seem to check for either '-' or '/' as a delimiter before the release version number, so until this is changed, you would have to add one or other after whatever you use as your release branch prefix. To use your example, change Release_0.99.1 to Release_-0.99.1. It doesn't look good, but should extract the version. You may want to change the regex for release branches in the config too.

I would see this as a bug in GitVersion, since the documentation does imply that your method should work.

Answer 2

Update your regex for your branches. For the release branch, for example, one of the following ought to work (in the order I would try these):

• regex: ^Release[_-/]
• regex: ^Release_[-/]?
• regex: ^Release[-/]?
• regex: ^Release[-/]?_

If you wanted to be even more specific, to ensure someone doesn't have a branch named something like Release_something_to_develop, then I might try to use either the first or the last one above with an additional qualifier:

• regex: ^Release[_-/]\d+\.\d+\.\d+
• regex: ^Release[-/]?_\d+\.\d+\.\d+

These aren't fool-proof since the regexes are "open-ended" (unless you use one of the two above and append a $ to the end of the regex). But it'd be unlikely someone would name their branch Release_0.0.1_to_production....