GitVersion produces different BuildMetaData once commit is tagged

[sebastianlux]

Repro Steps
First commit
Second commit <- Tagged with 1.2.0
Third commit <- pump minor via commit msg
Fourth commit

->Fourth commit now produces version number 1.3.0+2
-> Now tag the fourth commit with v1.3.0, aka we have released 1.3.0+2

Expected
When building the fourth commit, the exact same version information are produced by GitVersion, meaning 1.3.0+2

Actual
The fourth commit produces version information without any BuildMetaData, meaning the +2 is missing.

We usually take a build, test it, release it, and then tag the commit as released.
We do not know before the actual test whether we want to release (aka tag) the commit or not. But with this approach we are forced to tag the commit before the actual test to ensure that the version number of the commit does not change.

Edit:
Tested with GitVersion 3.6.5 and 4.0.0-beta0012

[sebastianlux]

Any update on this?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[jklaus]

I am seeing strange behavior with the metadata being off now as well. Started a couple weeks back.

[asbjornu]

With which version of GitVersion are you experiencing this, @jklaus?

[jklaus]

@asbjornu 5.0.1, in Azure DevOps.

[asbjornu]

Could you please update to version 5.3.4 and see whether the problem is reproducable there as well?

[jklaus]

I can investigate it but I think we're just using w/e the latest version is that the default build step installs. Not sure if it will allow me to download that far forward from where it currently is.

[jklaus]

@asbjornu scratch that.. looks like the step they're using has been deprecated. I'll tell them to install and port to the latest step, that's likely what the issue is.

[asbjornu]

I just realised that the "bug" experienced here is by design. A tag will reset the commit count. That's how GitVersion works.

[jklaus]

It used to behave such that it was commits ahead of mainline though.. not commits ahead of the current branch.