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...

[horihel]

so you think this is a bug and not a configuration mistake?

[HHobeck]

I don't know what it is. But it would be good to have it reproducable

[horihel]

I mocked up a small repro repo at https://github.com/horihel/versiontest

If you switch to branch "releases/0.3" it will give you 0.0.1-rc instead of 0.3.0-rc

[HHobeck]

The tag prefix needs to be set to optional tag-prefix: (tags/)? otherwise it needs to be part of the branch name:

[horihel]

Thank you - that seems to do the trick

I still have to set semantic-version-format: Loose and will need to check that for side-effects, but I think I should be able to make it behave like 5.x did.

[horihel]

okay, now I'm running against the same problem as #4161
gitversion picks up the PR number as major version (even if pull-request has is-release-branch: false)

I've tried adding my prefix to the branch pattern to force detection only with that branch: version-in-branch-pattern: (releases/)(?<version>[vV]?\d+(\.\d+)?(\.\d+)?).* but gitversion seperates the bits on (/) and checks them individually against the regex, so that can't work.

I'm running out of ideas - as long as version-in-branch-pattern and/or semantiv-version-format are globals, I can't have release branches and PRs produce correct version numbers.... The only thing I can try would be having different GitVersion.yml files for normal builds and PRs and replacing them in the pipeline...

Update: I'm seeing a bit of a light by setting branches.pull-request.increment to "Patch" or "Minor". "Inherit" seems to override the local is-release-branch and activates version-in-branch-pattern.

[horihel]

First - big thanks to @HHobeck for helping me.

To summarize, this is the combined solution:

semantic-version-format: Loose will allow GitVersion to read incomplete versions from branches at all (like my releases/0.5).

Unfortunately the side effect is that it does this for all numbers on all branch configurations now, including pull requests. This is described in #4161 already as a side effect.

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.

The final configuration is then:

tag-prefix: (tags/)?
update-build-number: false
branches:
  pull-request:
    increment: Patch
  main:
    label: alpha
    increment: Minor
    tracks-release-branches: true
  release:
    increment: Patch
    label: rc
    prevent-increment:
      when-current-commit-tagged: true
semantic-version-format: Loose

This is still not optimal, because PRs will now generate too low version numbers in many cases, but any configuration that helps it (like track-merge-target will re-enable version-in-branch-pattern.

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.

[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.