develop pre-release number (CommitsSinceVersionSource) regresses when an older-line hotfix tag is merged up — allow anchoring the version source to the line's branch-off / version-bump point

[JTLMarcVoelker]

Summary

In GitFlow, a hotfix released on an older line (e.g. 1.1.1) must be merged back up into develop so the fix is present there. As soon as that hotfix tag becomes reachable from develop, GitVersion picks it as the VersionSource, and CommitsSinceVersionSource is recomputed from that later tag. Because the hotfix tag sits after the previous baseline, the pre-release counter on develop decreases, so the emitted version goes backwards (e.g. 1.2.0-beta.168 → 1.2.0-beta.91).

This is not just cosmetic: on an append-only integration branch the counter later climbs again and re-emits pre-release versions that were already published with different content (1.2.0-beta.91 … 168 a second time), which causes package-feed collisions (NuGet treats identical version strings as the same package).

Environment

• GitVersion 6.5.1 (GitVersion.MsBuild), workflow: GitFlow/v1
• develop labeled beta; integration branches are append-only (no squash/rebase), hotfixes are merged up as required by GitFlow.

Reproduction

# main has the last minor release, merged into develop; develop => 1.2.0-beta.N
git tag 1.1.0
# ... many commits on develop ... => 1.2.0-beta.<large N>

# hotfix on the released 1.1 line
git checkout main && git switch -c hotfix/1.1.1
git commit -am "fix"
git switch main && git merge --no-ff hotfix/1.1.1 && git tag 1.1.1

# merge the fix UP into develop (mandatory in GitFlow, so the fix is in develop)
git switch develop && git merge --no-ff main

develop now reports 1.2.0-beta.M with M = commits since 1.1.1, which is smaller than the previous N (commits since 1.1.0).

Actual behavior

VersionSource moves from 1.1.0 to 1.1.1; CommitsSinceVersionSource drops → the develop pre-release number regresses and can later collide with already-published versions.

Expected / requested behavior

develop's counting anchor should be the point where the current line was established — i.e. the commit where develop incremented to its current version (typically where the last release/* branch was derived) — independent of older-line tags that are merged up afterwards. In other words, a tag whose Major.Minor is below the version develop is currently working towards should not become develop's VersionSource.

This would keep the merged-up fix present in develop (commits merged) while keeping the pre-release number monotonic (tag not used as counting anchor).

Current workaround (and why it's insufficient)

ignore.sha for each hotfix tag works, but requires a manual entry per hotfix; there is no rule/regex to exclude "tags below the current line" automatically. next-version does not help (verified: VersionSource still moves to the hotfix tag). A configurable behavior (e.g. "anchor develop to the line's branch-off point" / "ignore version sources below the target Major.Minor") would solve this generally.

[JTLMarcVoelker]

Clarification on the concrete trigger in our setup:

In our repository the reset is triggered by merging main into develop (to keep develop in sync), which pulls main's tagged release/hotfix merge-commit into develop's ancestry. The tag sits on the main-side merge commit (Merge branch 'hotfix/1.1.1'); the actual fix commit on the hotfix branch is untagged. So this is admittedly a deviation from canonical GitFlow — there you'd merge the hotfix/* (or release/*) branch back into develop, which brings the fix commits without making the tag reachable from develop, and the pre-release counter would not reset.

That said, I think the request still stands: merging main into develop is a common real-world practice (syncing merge commits / CI / config back), and even then a release/hotfix tag whose Major.Minor is below the version develop is working towards should not become develop's VersionSource and reset its pre-release counter — which regresses the version and can re-emit already-published pre-release versions (feed collision).

A configurable behavior would make GitVersion robust to this without forcing teams to avoid main → develop merges, e.g.:

• anchor develop's counting to its own line (the branch-off / version-bump point), or
• ignore version sources whose Major.Minor is below the version develop is targeting.

Workaround we use meanwhile: ignore.sha for the offending tag commit (verified — VersionSource falls back to the previous minor tag and the counter grows monotonically again). It just needs a manual entry per hotfix, which is why a general rule/option would be preferable.

[HHobeck]

I think it would be best to continue this discussion in 4664, since it covers the same topic.

• Hotfix branch merge resulting in pre-release number reset #4664

I'm definitely open to improving this, but at the moment I don't see what should be changed in the algorithm. Could you elaborate a bit on how you think it should behave instead?

The value used as the pre-release number is the number of commits since the last release, which reflects the repository history. Based on your description, it sounds like this might be related to your release or branching strategy rather than the algorithm itself.

If you're running into version conflicts, a few approaches that may help are:

• Ensure that hotfixes are merged into main before they are merged back into develop.
• Ensure that dedicated commits and merge commits are preserved in the history.
• Consider using ManualDeploymentMode: https://gitversion.net/docs/reference/modes/manual-deployment

From what you've described, I think the reason the number decreases is that your develop branch contains a commit that is also part of the hotfix, which affects the commit count since the last release.

Hope that makes sense.

Cheers!