Commit Counts and Tags

[igloo15]

How do tags affect Commit Count on Develop branch? I have found that tags now reset the commit count as of version 3.0.1 where in version 3.0.0 they only affected the version number when on master branch. Now any version tag resets the develop branch's commit count.

For instance I have a 2.0.0-alpha tag on develop and it resets my commit counter. Before it would ignore that and go back to when develop last merged with master. The documentation doesn't seem to match up with what is actually happening.

[JakeGinnivan]

Could you give me a bit more context? What was the version on develop before the tag?

[igloo15]

So with the tag 2.0.0-alpha on develop the version was for FullSemVer: 2.0.0-unstable.33

33 denoting 33 commits from that tag.

If I delete the tag 2.0.0-alpha on develop than the version is 2.0.0-unstable.142

142 denoting 142 commits since last mergeCommitDate with master I assume.

In version 3.0.0 of GitVersion tool I got 142 with the tag in 3.0.1 I get the 33.

[JakeGinnivan]

Can you run the exe and paste the logs? gitversion /l console

There were a number of commit counting bugs in 3.0.0 which were fixed.

[igloo15]

Log with a Tag on develop : http://pastebin.com/NVLWJ96h
Log without a Tag on develop : http://pastebin.com/Dx1WDRbM

In the above example its actually 4.0.0 and the Tag is 4.0.0-rc.1. Both where taken with GitVersion 3.0.1. Also the first log has the tag then I deleted it and ran again and produced the second log.

[JakeGinnivan]

So there was a bug in 3.0.0 which happened to make this scenario work..

The issue (as it stands) is that you have used next-version: to bump the version number instead of a release branch. The problem is that GitVersion doesn't go to the effort of finding out which commit the next-version config flag was put in, so that is not counted as a commit source.

This is stepping through the current logic:

1. Out of all the sources for versions, increment them all based on the rules then find the max incremented version (in your case 4.0.0 from the next-version: 4.0.0 value)
2. Check to see if there are any other values which are the same as the max (in your case no, the tags are all pre-release, not stable)
3. Try to find the commit counting source. Your current max version doesn't have a source, so we:
   • Filter out all versions which do not have a commit source (left with the pre-release tags)
   • Order by the version number (descending)
   • Then order by the commit date (descending)
   • Take the first version

Based on this flow your commit counting will always be from the latest tag. Ideas on how to fix are welcome. The failing test I created is:

[Test]
public void TagOnDevelopShouldNotReset()
{
    using (var fixture = new EmptyRepositoryFixture(new Config
    {
        VersioningMode = VersioningMode.ContinuousDeployment,
        NextVersion = "4.0.0"
    }))
    {
        const string TaggedVersion = "1.0.3";
        fixture.Repository.MakeATaggedCommit(TaggedVersion);
        fixture.Repository.CreateBranch("develop");
        fixture.Repository.Checkout("develop");

        fixture.Repository.MakeCommits(5);
        fixture.AssertFullSemver("4.0.0-unstable.5");

        fixture.Repository.MakeCommits(5);
        fixture.Repository.ApplyTag("4.0.0-alpha");
        fixture.AssertFullSemver("4.0.0-alpha");
        fixture.Repository.MakeCommits(5);

        fixture.AssertFullSemver("4.0.0-unstable.10");

        fixture.Repository.MakeCommits(5);
        fixture.Repository.ApplyTag("4.0.0-beta");
        fixture.AssertFullSemver("4.0.0-unstable.15");
    }
}

[JakeGinnivan]

@igloo15 did you see my response?

[igloo15]

Thanks yeah in the end I just removed the offending tags and worked around it.

Thanks