Cannot get version-in-branch-name to work on 6.3

[horihel]

Hi guys,

here's my use-case:

i have a "master" branch and several release branches (releases/0.3, releases/0.4) with tags on them.
I have a new release branch (releases/0.5) with no tags on it yet.

expectation was that gitversion would take the version indicator (0.5) and use that. Instead it uses a 0.4.x tag as a base version.

This used to work on 5.x but with 6.3 i can't figure out a working configuration.

My current config looks like this:

tag-prefix: tags/
update-build-number: false
branches:
  main:
    label: alpha
    increment: Minor
    tracks-release-branches: true
  release:
    increment: Patch
    label: rc
    prevent-increment:
      when-current-commit-tagged: true

Logs:

2025-07-28 09:52:24		INFO [25-07-28 9:52:24:34] Working directory: D:\HTA\repos\hh-WeatherApp
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:36] Project root is: D:\HTA\repos\hh-WeatherApp\
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:36] DotGit directory is: D:\HTA\repos\hh-WeatherApp\.git
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:36] Branch from build environment: 
2025-07-28 09:52:24		DEBUG [25-07-28 9:52:24:36] Trying to find configuration file GitVersion.yml at 'D:\HTA\repos\hh-WeatherApp'
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:36] Found configuration file at 'D:\HTA\repos\hh-WeatherApp\GitVersion.yml'
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:36] Using configuration file 'D:\HTA\repos\hh-WeatherApp\GitVersion.yml'
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:47] Using latest commit on specified branch
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:48] Getting tagged semantic versions. TagPrefix: tags/ and Format: Strict
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:52] Running against branch: releases/0.5 ('153e7f4' - Merged PR 65271: small change)
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:53] -< Begin: Fetching the base versions for version calculation... >-
2025-07-28 09:52:24		  INFO [25-07-28 9:52:24:53] -< Begin: Calculating base versions for 'releases/0.5' >-
2025-07-28 09:52:24		    INFO [25-07-28 9:52:24:53] -< Begin: [Using 'ConfiguredNextVersionVersionStrategy' strategy] >-
2025-07-28 09:52:24		    INFO [25-07-28 9:52:24:53] -< End: [Using 'ConfiguredNextVersionVersionStrategy' strategy] (Took: 0.55ms) >-
2025-07-28 09:52:24		    INFO [25-07-28 9:52:24:53] -< Begin: [Using 'MainlineVersionStrategy' strategy] >-
2025-07-28 09:52:24		    INFO [25-07-28 9:52:24:53] -< End: [Using 'MainlineVersionStrategy' strategy] (Took: 0.45ms) >-
2025-07-28 09:52:24		    INFO [25-07-28 9:52:24:53] -< Begin: [Using 'MergeMessageVersionStrategy' strategy] >-
2025-07-28 09:52:24		    INFO [25-07-28 9:52:24:56] -< End: [Using 'MergeMessageVersionStrategy' strategy] (Took: 22.50ms) >-
2025-07-28 09:52:24		    INFO [25-07-28 9:52:24:56] -< Begin: [Using 'TaggedCommitVersionStrategy' strategy] >-
2025-07-28 09:52:24		      INFO [25-07-28 9:52:24:56] -< Begin: Getting tagged semantic versions on branch 'refs/heads/releases/0.5'. TagPrefix: tags/ and Format: Strict >-
2025-07-28 09:52:24		        DEBUG [25-07-28 9:52:24:56] Returning cached tagged semantic versions. TagPrefix: tags/ and Format: Strict
2025-07-28 09:52:24		      INFO [25-07-28 9:52:24:56] -< End: Getting tagged semantic versions on branch 'refs/heads/releases/0.5'. TagPrefix: tags/ and Format: Strict (Took: 1.40ms) >-
2025-07-28 09:52:24		      DEBUG [25-07-28 9:52:24:57] Returning cached tagged semantic versions. TagPrefix: tags/ and Format: Strict
2025-07-28 09:52:24		      INFO [25-07-28 9:52:24:58] Git tag 'tags/0.4.0': Version increment '0.4.0' +semver 'Patch' with label 'rc' based on commit '448f8eb'.
2025-07-28 09:52:24		      DEBUG [25-07-28 9:52:24:58] Returning cached tagged semantic versions. TagPrefix: tags/ and Format: Strict
2025-07-28 09:52:24		      INFO [25-07-28 9:52:24:58] Git tag 'tags/0.4.1': Version increment '0.4.1' +semver 'Patch' with label 'rc' based on commit '448f8eb'.
2025-07-28 09:52:24		      DEBUG [25-07-28 9:52:24:58] Returning cached tagged semantic versions. TagPrefix: tags/ and Format: Strict
2025-07-28 09:52:24		      INFO [25-07-28 9:52:24:58] Git tag 'tags/0.2.0': Version increment '0.2.0' +semver 'Patch' with label 'rc' based on commit '096d01d'.
2025-07-28 09:52:24		    INFO [25-07-28 9:52:24:58] -< End: [Using 'TaggedCommitVersionStrategy' strategy] (Took: 23.43ms) >-
2025-07-28 09:52:24		    INFO [25-07-28 9:52:24:58] -< Begin: [Using 'TrackReleaseBranchesVersionStrategy' strategy] >-
2025-07-28 09:52:24		    INFO [25-07-28 9:52:24:58] -< End: [Using 'TrackReleaseBranchesVersionStrategy' strategy] (Took: 0.44ms) >-
2025-07-28 09:52:24		    INFO [25-07-28 9:52:24:58] -< Begin: [Using 'VersionInBranchNameVersionStrategy' strategy] >-
2025-07-28 09:52:24		    INFO [25-07-28 9:52:24:58] -< End: [Using 'VersionInBranchNameVersionStrategy' strategy] (Took: 3.56ms) >-
2025-07-28 09:52:24		  INFO [25-07-28 9:52:24:59] -< End: Calculating base versions for 'releases/0.5' (Took: 54.10ms) >-
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:59] -< End: Fetching the base versions for version calculation... (Took: 56.08ms) >-
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:59] -------------------------------------------------------
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:59] Base version used: Git tag 'tags/0.4.1': Take '0.4.1' based on commit '448f8eb'.
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:59] -------------------------------------------------------
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:59] -< Begin: Using continuous delivery workflow to calculate the incremented version. >-
2025-07-28 09:52:24		  INFO [25-07-28 9:52:24:59] 8 commits found between '448f8eb' - Merged PR 60783: fix dependency error and '153e7f4' - Merged PR 65271: small change
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:59] -< End: Using continuous delivery workflow to calculate the incremented version. (Took: 1.56ms) >-
2025-07-28 09:52:24		DEBUG [25-07-28 9:52:24:59] Returning cached tagged semantic versions on branch 'refs/heads/releases/0.5'. TagPrefix: tags/ and Format: Strict
2025-07-28 09:52:24		DEBUG [25-07-28 9:52:24:59] Trying to find configuration file GitVersion.yml at 'D:\HTA\repos\hh-WeatherApp'
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:59] Found configuration file at 'D:\HTA\repos\hh-WeatherApp\GitVersion.yml'
2025-07-28 09:52:24		INFO [25-07-28 9:52:24:59] Using configuration file 'D:\HTA\repos\hh-WeatherApp\GitVersion.yml'

It looks like the VersionInBranchNameVersionStrategy did run, but didn't detect my release branch at all.

[horihel]

i tried restricting strategies to only VersioninBranchName and it complains about no base version found... so it feels like the default regex doesn't seem to match my branch name any more (releases/0.5) - though 101regex tells me that it should match...

[asbjornu]

Personally i'm not sure if this is a bug or intended behavior. I also didn't find a way to find out, what increment: Inherit produces as a branch configuration, as it is unpredictable where it is inherited from (to my knowledge at least) and the documentation doesn't clearly state, which configuration parameters are actually inherited.

This sounds like something we need to document, yes. Each branch configuration should state what Inherit means in practice.

[HHobeck]

First - big thanks to @HHobeck for helping me.

Yes no problem. If you like you can sponsore me.

My workaround (that at least prevents gitversion from generating major versions in the high thousands) was setting increment: Patch. This prevents the pull-request branch configuration from inheriting the "is-release-branch" flag, which would cause version-in-branch-pattern to be enabled.

I'm a little bit confused: You have stated that the "is-release-branch" flag is the reason why PRs are calculating the wrong version in your case but you are changing the increment. Why not just changing the is-release-branch flag to false on the pull-request branch configuration?

Personally I’m not sure if this is a bug or intended behavior.

Please give some advice how to make the algorithm better.

I also didn't find a way to find out, what increment: Inherit produces as a branch configuration, as it is unpredictable where it is inherited from (to my knowledge at least) and the documentation doesn't clearly state, which configuration parameters are actually inherited.

Like the name indicates it will inherit the branch related configuration properties (of course if not specified!!) from the parent branch. If you create a PR to lets say a release/1.0 branch, then your feature branch (branch where your changes are included) are merged to the pull-request branch. The pull request branch on the other hand was create from the release branch (That's the mechanism of how PRs are working in git). Thus the release branch is the parent branch. Same for main develop and so on.

Does this make sense to you?

See: https://gitversion.net/docs/learn/branching-strategies/gitflow/examples

[horihel]

My workaround (that at least prevents gitversion from generating major versions in the high thousands) was setting increment: Patch. This prevents the pull-request branch configuration from inheriting the "is-release-branch" flag, which would cause version-in-branch-pattern to be enabled.

I'm a little bit confused: You have stated that the "is-release-branch" flag is the reason why PRs are calculating the wrong version in your case but you are changing the increment. Why not just changing the is-release-branch flag to false on the pull-request branch configuration?

Sorry, i forgot to mention: it doesn't work. That was the first thing I tried, and it did not make a difference.

Personally I’m not sure if this is a bug or intended behavior.

Please give some advice how to make the algorithm better.

That probably makes sense once I understand the algorithm better :)

I also didn't find a way to find out, what increment: Inherit produces as a branch configuration, as it is unpredictable where it is inherited from (to my knowledge at least) and the documentation doesn't clearly state, which configuration parameters are actually inherited.

Like the name indicates it will inherit the branch related configuration properties (of course if not specified!!) from the parent branch. If you create a PR to lets say a release/1.0 branch, then your feature branch (branch where your changes are included) are merged to the pull-request branch. The pull request branch on the other hand was create from the release branch. Thus the release branch is the parent branch. Same for main develop and so on.

Does this make sense to you?

So for me that means in both cases that would mean it would inherit is-release-branch: true from the other branches. But setting it to false in the pull-request: configuration did not change it. Does the inheritance take precedence? How can I check?

[HHobeck]

Does the inheritance take precedence? How can I check?

No. Degugging?

[horihel]

Does the inheritance take precedence? How can I check?

No. Degugging?

I'm afraid that's a bit beyond my capabilities (not a developer) - but I can try.