Reported Versions Out of Order After Prerelease Tag

[WalkerCodeRanger]

With the following GitVersion.yml

mode: ContinuousDeployment
branches:
  master:
    tag: dev

The table below shows 4 commits on the master branch, oldest to newest. The middle column indicates what tags have been created in git (git tag something). The third column shows the version GitVersion assigns to them.

Commit #	Git Tag	GitVersion
1	v2.0.0	2.0.0
2		2.0.1-dev.1
3	v2.1.0-rc	2.1.0-rc
4		2.1.0-dev.1

This all seems correct up until commit 4. Notice that according to SemVer 2.0.0 < 2.0.1-dev.1 < 2.1.0-rc, but 2.1.0-rc > 2.1.0-dev1.

After a release git tag, GitVersion increments the version number, but after a prerelease git tag, it doesn't. That makes some sense if tag: '' is set and the new version wil be -rc.X, but doesn't make sense in this case.

I think that if the branch tag setting would cause the current version to be before the previous tag, then the increment should happen.

[asbjornu]

Which version of GitVersion are you using? Are you able to reproduce the error in a RepositoryFixture test akin to the following?

GitVersion/src/GitVersionCore.Tests/IntegrationTests/MasterScenarios.cs

Lines 35 to 56 in 92c11a1

	[Test]
	public void CanHandleContinuousDeployment()
	{
	var config = new Config
	{
	Branches =
	{
	{
	"master", new BranchConfig
	{
	VersioningMode = VersioningMode.ContinuousDeployment
	}
	}
	}
	};
	using(var fixture = new EmptyRepositoryFixture())
	{
	fixture.Repository.MakeATaggedCommit("1.0.0");
	fixture.Repository.MakeCommits(2);
	fixture.AssertFullSemver(config, "1.0.1-ci.2");
	}
	}

[WalkerCodeRanger]

I'm using version 5.0.1+Branch.master.Sha.c71b8fc9f6d7b6adffe82fef588e717beb864e91

I've created a failing unit test that shows the issue. I put it in VersionBumpingScenarios because it seemed to go along with the current AppliedPrereleaseTagCausesBump test.

https://github.com/WalkerCodeRanger/GitVersion/blob/fdbe5b4fed22b81c6dc295b5e2c7e5ec9c36211e/src/GitVersionCore.Tests/IntegrationTests/VersionBumpingScenarios.cs#L38-L63

Should I submit a pull request with that code?

[asbjornu]

A PR would be great. If you would dare attempt to figure out why GitVersion is acting up, that would be even better. 😃

[WalkerCodeRanger]

Debugging the unit test in my PR #1845 to see why this is happening...

NextVersionCalculator.FindVersion() gets the base version and then tries to increment it and correct the prerelease tag:

GitVersion/src/GitVersionCore/VersionCalculation/NextVersionCalculator.cs

Lines 54 to 64 in 92c11a1

	semver = PerformIncrement(context, baseVersion);
	semver.BuildMetaData = metaDataCalculator.Create(baseVersion.BaseVersionSource, context);
	}
	var hasPreReleaseTag = semver.PreReleaseTag.HasTag();
	var branchConfigHasPreReleaseTagConfigured = !string.IsNullOrEmpty(context.Configuration.Tag);
	var preReleaseTagDoesNotMatchConfiguration = hasPreReleaseTag && branchConfigHasPreReleaseTagConfigured && semver.PreReleaseTag.Name != context.Configuration.Tag;
	if (!semver.PreReleaseTag.HasTag() && branchConfigHasPreReleaseTagConfigured || preReleaseTagDoesNotMatchConfiguration)
	{
	UpdatePreReleaseTag(context, semver, baseVersion.BranchNameOverride);
	}

PerformIncrement() ends up calling SemanticVersion.IncrementVersion() on a pre-release version (the base version coming from the tag) with VersionField.Patch. But that checks for pre-release:

GitVersion/src/GitVersionCore/SemanticVersion.cs

Line 291 in 92c11a1

if (!incremented.PreReleaseTag.HasTag())

and then only increments the pre-release tag number if there is one:

GitVersion/src/GitVersionCore/SemanticVersion.cs

Lines 315 to 319 in 92c11a1

	if (incremented.PreReleaseTag.Number != null)
	{
	incremented.PreReleaseTag.Number = incremented.PreReleaseTag.Number;
	incremented.PreReleaseTag.Number++;
	}

To me, that seems wrong. I asked it to increment the patch version and it didn't. Changing SemanticVersion.IncrementVersion() to not treat pre-release special, but to go ahead and increment (but possibly remove the pre-release tag) makes more sense. But doing that causes many more unit tests to break because the whole system depends on the current behavior.

I guess NextVersionCalculator.UpdatePreReleaseTag() could patch up the version number, but I don't understand things well enough to know what change to make there. Alternatively, NextVersionCalculator.FindVersion() could use preReleaseTagDoesNotMatchConfiguration to remove the prerelease tag and try to increment again, but that seems like a hack.

Is there any guidance you could offer on how to fix this?

[asbjornu]

Yes, now that you're starting to dig into this, I remember this being a complicated hot mess. Perhaps @arturcic remembers when we discussed this last and what the result of that discussion was? My memory is not my strongest asset. 😅

[asbjornu]

Will the fix implemented in #2003 help with this problem in any way?

[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.