[Bug] Version of commit in develop merged to master changes if master is tagged

[mycroes]

Describe the bug
In a repository where commit A from develop is merged into master as commit B, GitVersion generates a different version for commit A if B is tagged with a version.

Expected Behavior

GitVersion produces version (5.1.0-alpha.15+Branch.develop.Sha.ffaca48e8c7bf98e28bccbec0ee8816178f78470) based on history of commit A in develop, as it does when B is not tagged.

Actual Behavior

GitVersion produces version (6.1.0-alpha.0+Branch.develop.Sha.ffaca48e8c7bf98e28bccbec0ee8816178f78470) based on the 'future' merge of A into master as commit B with tag v6.0.0

Possible Fix

Ignore all commits derived from current commit in version calculation.

Steps to Reproduce

1. Create commit A on develop
2. Run GitVersion, take note of version generated
3. Merge commit A into master, generating commit B
4. Tag commit B with next release version
5. Checkout develop (still pointing to commit A)
6. Run GitVersion, take note of version generated

Context

Affects builds that deploy packages when the package deployment is ran after the merge commit has also been tagged. We deploy packages using Jenkins on merge in Gerrit, so there's a fair chance of this happening on the last commits before release.

Your Environment

• Version Used: 5.10.1
• Windows 10

[asbjornu]

Different commits on different branches produce different version numbers. That's sort of the entire point of GitVersion. I don't see the problem here?

[mycroes]

The same commit on the same branch produces a different version number (after a new commit is added), that seems pretty awkward to me.

[asbjornu]

What you are seeing is GitVersion working as it should. develop should always produce a higher version number than main or master. This is by design.

[mycroes]

Please carefully read the original issue. I fully understand what you're saying, that's not the issue I'm having. Thanks for looking into this!

[asbjornu]

Can you please create a RepositoryFixture test that performs all the necessary steps as well as the version number assertions you expect along the way?

[HHobeck]

    [Test]
    public void __Just_A_Test__()
    {
        using EmptyRepositoryFixture fixture = new("develop");

        var configBuilder = ConfigBuilder.New;

        // Create commit A on develop
        fixture.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("0.1.0-alpha.1", configBuilder.Build());

        // Branch develop to main
        fixture.BranchTo("main");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("0.0.1+1", configBuilder.Build());

        // Create commit B on main
        fixture.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("0.0.1+2", configBuilder.Build());

        // Tag commit B with next release version
        fixture.ApplyTag("1.0.0");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.0", configBuilder.Build());

        // Checkout develop (still pointing to commit A)
        fixture.Checkout("develop");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.1.0-alpha.0", configBuilder.Build());

        // Merge changes from main to develop
        fixture.MergeNoFF("main");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.1.0-alpha.1", configBuilder.Build());
    }

Actually this is maybe fixed in the PR #3190 . Are you agree?

[mycroes]

Thx @HHobeck, I'm short on time and didn't know it would be this easy to write a test for it. This shows exactly what I meant, good work.

Edit: not sure if PR fixes this, but the test matches

[arturcic]

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

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot 📦🚀