New tag is ignored if the older +semver: suggests higher version

[patrikbeno]

Describe the bug
Series of +semver: commit messages bumps version up to next major, e.g. 2.0.0.
Explicit tag says 1.1.0.
Next commit still suggests 2.0.0

Expected Behavior

Explicit tag should take priority over the messages in commit history.
Tag should reset the calculation of the version from message history before the tag.
Latest tag should be considered new baseline, and only messages in commit history following the tag should be considered.

Actual Behavior

Tag is ignored completely, and +semver: commit history wins.

Possible Fix

Ignore commit history before the tag.

Steps to Reproduce

$ git log --oneline
9514c9e (HEAD -> main)  #(2.0.0+7)
d749b10 +semver: none #(2.0.0+6)
6d6eace (tag: 1.1.0) +semver: fix #(2.0.0+5)
a0b2e0e +semver: feature #(2.0.0+4)
77f5a4a +semver: major #(2.0.0+3)
842d1ce +semver: feature #(1.1.0+2)
8ca3e12 +semver: fix #(1.0.1+1)
9f90368 (tag: 1.0.0) initial

Context

Message in commit history suggested bumping the major version.
This is later considered as mistake.
History is written, and its rewrite is not possible.
Explicit tag is used to reset/baseline the automated version calculation.

Your Environment

Windows 10
GitVersion 5.9.0

[patrikbeno]

Another view:

[main (root-commit) f0e3c9b] initial
tagging: 1.0.0
[main bb045e8] +semver: fix
1.0.1+1
[main 1a1d875] +semver: feature
1.1.0+2
[main 261a0c0] +semver: major
2.0.0+3
[main 99523f7] +semver: feature
2.0.0+4
[main 68077bf] +semver: fix
2.0.0+5
tagging: 1.1.0
[main b65ddac] +semver: none
2.0.0+6
[main ea21499] 
2.0.0+7
DONE

INFO [04/09/22 9:41:38:38] Begin: Calculating base versions
  INFO [04/09/22 9:41:38:39] Fallback base version: 0.1.0 with commit count source f0e3c9b02c29fa395950407d8906a4e10de7f686
  INFO [04/09/22 9:41:38:41] Git tag '1.1.0': 1.1.0 with commit count source 68077bfdb6fd074c51657d3c8a7a9a07f140ba81
  INFO [04/09/22 9:41:38:41] Git tag '1.0.0': 1.0.0 with commit count source f0e3c9b02c29fa395950407d8906a4e10de7f686
  INFO [04/09/22 9:41:38:44] Found multiple base versions which will produce the same SemVer (2.0.0), taking oldest source for commit counting (Git tag '1.0.0')
  INFO [04/09/22 9:41:38:44] Base version used: Git tag '1.0.0': 1.0.0 with commit count source f0e3c9b02c29fa395950407d8906a4e10de7f686
  INFO [04/09/22 9:41:38:44] End: Calculating base versions (Took: 59.13ms)
  INFO [04/09/22 9:41:38:44] 7 commits found between f0e3c9b initial and ea21499 
  INFO [04/09/22 9:41:38:44] 7 commits found between f0e3c9b initial and ea21499 
Executing GenerateSetVersionMessage for 'LocalBuild'.

Executing GenerateBuildLogOutput for 'LocalBuild'.
2.0.0+7
  INFO [04/09/22 9:41:38:46] Done writing 

This is the problem, I guess:

Found multiple base versions which will produce the same SemVer (2.0.0), taking oldest source for commit counting (Git tag '1.0.0')

Those multiple versions are (1) old +semver: major commit message, and (2) new 2.0.0 tag.

When considering these two, new tag should win.

[asbjornu]

It is by design that the highest possible version number will be used, not the latest.

[patrikbeno]

It is by design that the highest possible version number will be used, not the latest.

Yes, but this applies to conflict resolution, when there are mutliple possible version candidates.

However, if there is one single specific 1.1.0 tag on a current commit, it used despite the fact that commit history suggests 2.0.0 version. That's because there is no conflict.

Now, adding a simple +semver: none commit bumps version to 2.0.0.

Why? This behavior is not only inconsistent, it also does not make any sense.

[asbjornu]

I agree this doesn't make much sense. Since the change in behavior around this can be seen as a breaking change, we may want to change this in main rather than in support/5.x. It can also be seen as a bugfix that can be applied directly to support/5.x. Thoughts? Also, would you be up for providing a PR that changes this behavior?

[arturcic]

🎉 This issue has been resolved in version 5.10.3 🎉
The release is available on:

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot 📦🚀

[gbtb]

I agree this doesn't make much sense. Since the change in behavior around this can be seen as a breaking change, we may want to change this in main rather than in support/5.x. It can also be seen as a bugfix that can be applied directly to support/5.x. Thoughts? Also, would you be up for providing a PR that changes this behavior?

That was indeed a breaking change for us 🥲 Upgraded from 5.9 to 5.12 and suddenly version calculation skyrocketed from 2 seconds to 39. I've bisected it to 5.10.1 - 5.10.2 update, and thankfully diff was small.
commit-message-incrementing: Disabled fixed the problem. I guess it happened because we haven't use commit message incrementing at all, and because of that it started to scan whole repo history.

[asbjornu]

@gbtb, I'm glad you figured out a fix and thankful that you reported it back here. 🙏🏼

[luka-grabarevic]

You guys sure this behavior is as intended? I've pinned down our sudden versioning issues to this PR #3078.

We have a tag v4.11.0 which was our last release.
We have a tag v4.12.0-beta.1 which is our new beta release.

Previously to this change our builds on master/main produced this output:

INFO [10/16/23 13:04:26:59] Found multiple base versions which will produce the same SemVer (4.12.0), taking oldest source for commit counting (Git tag 'v4.11.0')
INFO [10/16/23 13:04:26:59] Base version used: Git tag 'v4.11.0': 4.11.0 with commit count source 824f70807c7f3711b99aa6e8a80416155f3260ac

now this comes out:

INFO [10/16/23 13:03:26:98] Found multiple base versions which will produce the same SemVer (4.12.0-beta.2), taking oldest source for commit counting (Git tag 'v4.12.0-beta.1')
INFO [10/16/23 13:03:26:98] Base version used: Git tag 'v4.12.0-beta.1': 4.12.0-beta.1 with commit count source c986cb959b7df6606a59c4c62eea993ac270cdaa

For the release/4.12.0 branch the second behavior is correct, but not for a master/main build.