[Feature] Inconsistency between version bumping through Commit messages and Branch name

[Crown0815]

Describe the bug

The following test

[Test]
public void With_numbered_release_branch()
{
    using var fixture = new EmptyRepositoryFixture();
    fixture.Repository.MakeACommit();
    fixture.Checkout(MainBranch);
    fixture.Repository.ApplyTag("1.2.1");
    
    fixture.BranchTo("develop");
    fixture.Repository.MakeACommit("to be released");
    fixture.BranchTo("release/1.3.0");
    fixture.Repository.MakeCommits(1);
    fixture.Repository.ApplyTag("1.3.0-beta.1");
    fixture.Checkout("develop");
    fixture.Repository.MakeACommit("new development");

    fixture.AssertFullSemver("1.4.0-alpha.1");
}

produces

@startuml
create participant main
note over "main" #D3D3D3
  1.2.1
end note
create participant develop
main -> develop: branch from main
create participant "release/1.3.0"
develop -> "release/1.3.0": branch from develop
note over "release/1.3.0" #D3D3D3
  1.3.0-beta.1
end note
note over develop #D3D3D3
  1.4.0-alpha.1
end note
@enduml

with a final version on develop of 1.4.0-alpha.1. This is as expected and documented in the minor release branches example for gitflow.

In our case, we use conventional commits and bump our version based on those. Therefore, we do not use numbered release branches, but give them random names as exemplified by the following test

[Test]
public void MyTest()
{
    using var fixture = new EmptyRepositoryFixture();
    fixture.Repository.MakeACommit();
    fixture.Checkout(MainBranch);
    fixture.Repository.ApplyTag("1.2.1");
    
    fixture.BranchTo("develop");
    fixture.Repository.MakeACommit("semver: feature");
    fixture.BranchTo("release/some_release");
    fixture.Repository.MakeCommits(1);
    fixture.Repository.ApplyTag("1.3.0-beta.1");
    fixture.Checkout("develop");
    fixture.Repository.MakeACommit("semver: feature");

    fixture.AssertFullSemver("1.4.0-alpha.1");
}

However, this test fails by producing 1.3.0-alpha.2, as shown below

@startuml
create participant main
note over "main" #D3D3D3
  1.2.1
end note
create participant develop
main -> develop: branch from main
create participant "release/some_release"
develop -> "release/some_release": branch from develop
note over "release/some_release" #D3D3D3
  1.3.0-beta.1
end note
note over develop #D3D3D3
  1.3.0-alpha.2
end note
@enduml

Expected Behavior

I would expect the test to produce 1.4.0-alpha.1

Actual Behavior

The test produces 1.3.0-alpha.2

Possible Fix

I suspect the issue is that the versioning is based on the release branch name instead of the tag on the release branch. By changing the logic to target the tag on the release branch, the correct version might be created.

Steps to Reproduce

See above

Context

See above

Your Environment

• Version Used: d0a673a74502712b8a56fd6d361c0e0a7c0cb5a2
• Operating System and version (Windows 10, Ubuntu 18.04): Windows 10
• ~~Link to your project:~~
• ~~Link to your CI build (if appropriate):~~

Notes

If this is actually found to be a bug, I would be happy to provide a pull request to fix it.

[asbjornu]

You may try to configure source-branches for develop to include release.

[Crown0815]

@asbjornu Could you please elaborate why this should solve the issue? And why would this be necessary in case of using commit message bumping of version numbers but not in case of numbered release branches?

[asbjornu]

Because release is not a source branch for develop by default, and configuring it as such may force GitVersion to consider the tag on release when calculating the version for develop. I am not confident this is the case, but it's worth a try.

[Crown0815]

@asbjornu I adjusted my test according to your recommendation and still get the same result:

[Test]
public void MyTest()
{
    var config = new Config();
    config.Branches.Add("develop", new BranchConfig
    {
        SourceBranches = new HashSet<string>{"release"},
    });

    using var fixture = new EmptyRepositoryFixture();
    fixture.Repository.MakeACommit();
    fixture.Checkout(MainBranch);
    fixture.Repository.ApplyTag("1.2.1");
    
    fixture.BranchTo("develop");
    fixture.Repository.MakeACommit("semver: feature");
    fixture.BranchTo("release/some_release");
    fixture.Repository.MakeCommits(1);
    fixture.Repository.ApplyTag("1.3.0-beta.1");
    fixture.Checkout("develop");
    fixture.Repository.MakeACommit("semver: feature");

    fixture.AssertFullSemver("1.4.0-alpha.1", config);
}

should be 1.4.0-alpha.1 but was 1.3.0-alpha.2

Is the configuration correct, or do I need to adjust anything else?

[asbjornu]

Seems like the 1.3.0-beta.1 tag on release/some_release is not considered when computing the version on develop. The "proper" way to do it is to apply tags to main or master. That should bump develop as you expect.

[Crown0815]

But is this consistent with the claim made in the FAQs under Merged branch names as version source? To be fair, it is not about merged branches, but created branches. In case of the existence of branch release/1.3.0, the version of develop is bumped, but if the branch were to be deleted, the version(s) on develop would retrospectively reset. Would it not be more consistent to rely on the tags alone, since those are (at least more) persistent?

Maybe we are just using GitVersion incorrectly, but I have the impression that there is a slight inconsistency here.

[asbjornu]

Well, the expectation is to be able to use the branch name as a version source both when it exists and its presence in the merge message once it’s been merged and deleted. But since merge messages are customisable, no guarantee can be made about the branch name as a a version source. Therefore, adding a tag on the merged commit is recommended.

[github-actions[bot]]

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.

[github-actions[bot]]

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.

[HHobeck]

Like you sayed the documentation says clearly to use a dedicated version numer for branches e.g. release/1.2.3. Thus this issue is not a bug.