[Bug] Wrong version calculation

[387119]

Describe the bug
Issue with resetting pre-release number and increasing version for next flow
dev->spr->release->tag->spr->dev

Expected Behavior

Actual Behavior

1.0.0-2.spr.5 - didn't reset pre-release number
1.0.0-2.spr.7 - didn't increased Minor version and didn`t reset re-release number
1.1.0-2.spr.5 - pre-release number was reset after merge, due to this manual update "next-version" on earlier steps is not possible, because version can be duplicated

Possible Fix

possible solutions

• reset versions and pre-release numbers automatically
• additional option in GitVersion.yml for reset pre-release number per branch, like "pre-release-number: 0", similar to "next-version: 1.0"
• reset pre-release number by commit message

Steps to Reproduce

mkdir /tmp/gitv
cd /tmp/gitv
git init
#cp GitVersion.yml
git add .
git commit -m "Init"
git branch -m dev
git commit --allow-empty -m "commit"
git checkout -b spr/1
gitversion #obtained: "1.0.0-2.spr.1" , expected "1.1.0-2.spr.0"
git commit --allow-empty -m "commit"
git checkout -b release/1.0
git commit --allow-empty -m "commit"
git tag v1.0.0
git commit --allow-empty -m "commit"
git checkout spr/1
git merge release/1.0
gitversion #obtained: "1.1.0-2.spr.1", expected "1.1.0-2.spr.3"
git checkout dev
git commit --allow-empty -m "commit"
gitversion

Context

Your Environment

GitVersion.yml

next-version: 1.0
assembly-versioning-scheme: MajorMinorPatch
mode: ContinuousDeployment
commit-message-incrementing: Disabled
tag-prefix: v
branches:
  develop:
    regex: ^dev$
    source-branches: []
    tag: 1.dev
    increment: Major
    is-release-branch: false
  spr:
    regex: ^spr/
    source-branches: ['develop']
    tag: 2.spr
    increment: Minor
    is-release-branch: true
  release:
    source-branches: ['spr']
    tag: 3.rc
    increment: Patch
    is-release-branch: true
ignore:
  sha: []

• Version Used: docker gittools/gitversion:5.3.5-linux-centos.7-x64-netcoreapp2.1
• Operating System and version (Windows 10, Ubuntu 18.04): windows 10 and linux redhat 7.0
• Link to your project: -
• Link to your CI build (if appropriate): -

[asbjornu]

I'm not sure this is a bug. But if you could please write up your use-case as a RepositoryFixture and submit it as a pull-request, that would be very helpful in order to understand exactly what behaviour you're expecting here.

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

Lines 13 to 32 in 251645f

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

[ivan-danilov]

@asbjornu

// I'm working with the topic starter on this issue.

I'm not sure it is a bug either. Because of mixture of historical and political reasons we are not able to use one of the normal scenarios like GitFlow or GitHubFlow. Therefore, we tried to adapt GitVersion to our situation and it mostly worked out well until we bumped into this issue.

What we're trying to get is SemVer-compliant scheme along the following lines:

1. There's single dev branch, continuously going forward.
2. Approaching the time of the release, spr/1 branch is forked off of dev. At that point, dev is incremented to the next major version (by editing gitversion.yml). Any work toward 1.0.0 release is done in spr/1 and later merged to dev. dev itself now contains only the work for 2.0.0.
3. When we are ready to start making release candidates and code freeze, release/1.0 is forked from spr/1. It gets only the critical fixes and every commit there represents a release candidate. spr/1 branch gets less important fixes and minor additions that will be released in the Service Pack (hence the name spr), as well as downstream hotfix merges from release branch. Service Pack will be versioned 1.1.0, so minor version is bumped at this point in gitversion.yml.
4. Eventually, 1.0.0 gets released, which is marked with a tag. Later commits into release/1.0 are after-release hotfixes which are versioned through incrementing patch: 1.0.1, 1.0.2 etc

The problem we face is twofold:

1. After there's a tag in release/1.0 branch and its merged back to spr/1 - GitVersion starts counting height from the tagged version instead of continuing previous numbers. Because of that, PreReleaseNumber in the same spr/1 branch look like 1, 2, ..., 8, 9, 5 (the last one being count of commits from the tagged commit after merge while all previous are count of commits in spr/1 since forking it from dev. If I intentionally misconfigure tag-prefix for that GitVersion does not find it - the issue is fixed but then (expectably) there's no release 1.0.0 version where it should be and patch not incremented automatically (though, the latter can be fixed by manually editing next-version). Is there a way to tell gitversion to ignore version tags except for making final release versions?
2. Height is not reset to 0 (or 1) after manually changing next-version in gitversion.yml. It sounds pretty logical to me that after I manually bumped any component of the version - height counter should be started anew. Can I configure gitversion accordingly?

[asbjornu]

1. I think the problem may be that the tag doesn't occur on the master branch.
2. GitVersion doesn't track changes in next-version. The only way to achieve a significant history of versions GitVersion will pay attention to is to use git tag.

[HHobeck]

IMO related to #3041

[HHobeck]

Please see issue #3438. I think this issue is resolved in version 6.x:

[Test]
public void ActualBehaviorFor2287()
{
    var configuration = GitFlowConfigurationBuilder.New.Build();

    using var fixture = new EmptyRepositoryFixture();

    fixture.MakeACommit();

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

    fixture.ApplyTag("0.0.1");

    // ✅ succeeds as expected
    fixture.AssertFullSemver("0.0.1", configuration);

    fixture.BranchTo("develop");

    // ✅ succeeds as expected
    fixture.AssertFullSemver("0.0.1", configuration);

    fixture.MakeACommit();

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

    fixture.ApplyTag("0.1.0-alpha.1");

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

    fixture.MakeACommit();

    // ✅ succeeds as expected
    fixture.AssertFullSemver("0.1.0-alpha.2", configuration);

    fixture.BranchTo("release/0.1.0");

    // ✅ succeeds as expected
    fixture.AssertFullSemver("0.1.0-beta.1+0", configuration);

    fixture.MakeACommit();

    // ✅ succeeds as expected
    fixture.AssertFullSemver("0.1.0-beta.1+1", configuration);

    fixture.ApplyTag("0.1.0-beta.1");

    // ✅ succeeds as expected
    fixture.AssertFullSemver("0.1.0-beta.1", configuration);

    fixture.MakeACommit();

    // ✅ succeeds as expected
    fixture.AssertFullSemver("0.1.0-beta.2+1", configuration);

    fixture.ApplyTag("0.1.0-beta.2");

    // ✅ succeeds as expected
    fixture.AssertFullSemver("0.1.0-beta.2", configuration);

    fixture.Checkout("develop");

    // ✅ succeeds as expected
    fixture.AssertFullSemver("0.2.0-alpha.0", configuration);

    fixture.MakeACommit();

    // ✅ succeeds as expected
    fixture.AssertFullSemver("0.2.0-alpha.1", configuration);

    fixture.MergeNoFF("release/0.1.0");

    // ✅ succeeds as expected
    fixture.AssertFullSemver("0.2.0-alpha.4", configuration);
}

[arturcic]

🎉 This issue has been resolved in version 6.0.0-beta.2 🎉
The release is available on:

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot 📦🚀