No ability to increment Patch on subsequent commits

[konek3]

Describe the bug
The current flow of git in our repository is as follows:

1. main branch acts as stable branch.
2. feature branches are created from main branch.
3. pull requests are created from feature branch to main branch and merged.
4. During release, release branch is created from main branch with a format: "release/X.Y", where X is Major and Y is Minor.

The problem is GitVersion don't catch new commits that are pushed to release branch (for example cherry-picks from main branch in case of hotfixes). The version stays the same, but Patch number should be incremented. For example:

1. Branch "release/1.0" gets created. Gitversion generates version "1.0.0".
2. 3 new commits are pushed to release branch. GitVersion should generate version "1.0.3" but it stays at "1.0.0"

Property CommitsSinceVersionSource gets incremented though.

Current configuration I have:

mode: MainLine
branches:
  feature:
    regex: ^feature?[/-]
    source-branches: ["main"]
    increment: None
    tracks-release-branches: true
  release:
    regex: ^release?[/-]
    source-branches: ["main"]
    increment: Patch
    tag: ""
  main:
    is-mainline: true
    increment: None
    tag: useBranchName
    tracks-release-branches: true
    is-source-branch-for: ["feature", "release"]
    regex: (^main$|^origin\/main$)
update-build-number: true

Expected Behavior

After pushing new commits to release branch, Patch number should be incremented accordingly.

Actual Behavior

Patch number does not get incremented.

Is something wrong with my current configuration?

[HHobeck]

This issue seems to me not a bug report. Pleases create only bugs if you are sure it is a bug. Questions like: "Is something wrong with my current configuration?" might be an contra indication of that. :) Please use the discussion forum! Bugs needs to have clear defined steps to reproduce and the used version number.

[HHobeck]

I have tried to reproduce your issue but the result is like you would expecting it. Please see the following integration test:

public class MainlineDevelopmentMode3674 : TestBase
{
    private static IGitVersionConfiguration GetMainlineModeConfiguration() => GitFlowConfigurationBuilder.New
        .WithVersioningMode(VersioningMode.Mainline).WithLabel(null)
        .WithSemanticVersionFormat(SemanticVersionFormat.Loose)
        .WithBranch("develop", builder => builder
            .WithVersioningMode(VersioningMode.Mainline)
            .WithRegularExpression("^main")
            .WithIncrement(IncrementStrategy.Minor)
            .WithIsMainline(true)
            .WithLabel(null)
        ).WithBranch("release", builder => builder
            .WithVersioningMode(VersioningMode.Mainline)
            .WithIncrement(IncrementStrategy.Patch)
            .WithIsMainline(true)
            .WithIsReleaseBranch(true)
            .WithLabel(null)
        ).Build();

    [Test]
    public void JustATest()
    {
        var configuration = GetMainlineModeConfiguration();

        using var fixture = new EmptyRepositoryFixture("main");
        fixture.Repository.MakeATaggedCommit("1.0.0");
        fixture.Repository.MakeACommit();
        fixture.Repository.MakeACommit();

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

        fixture.BranchTo("release/1.2");

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

        fixture.Repository.MakeACommit("two");
        fixture.Repository.MakeACommit("three");

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

Probably you need to specify is-mainline on release and feature branch as well. The above test targeting 6.0.0-beta.3 pre-release version of git version but there is nothing against working in latest as well.

Happy branching!

[konek3]

Hi, thank you for the answer and sorry for wrong type of issue posted. Adding is-mainline: true seems to work! Could you explain why I need to specify it on all branches instead of only on "main" branch? Thanks!

[HHobeck]

I'm not the author of the mainline strategy and think that the code base is not so sophisticated like I would desire. But you are asking about my opinion what the motivation is: If you are not setting the is-mainline property to true, git version takes the branch as a side branch where release candidates will be created and tested until they are merged to the main branch (see Scenario 1). On the other hand there are multi-trunk based workflows which applies to your scenario (see Scenario 2).

Scenario 1:

• main branch with is-mainline true and patch increment
• release branch with is-mainline false and minor increment

     * 1.1.0 (merge commit)
     |\
     | * 1.1.0-2
     | |
     | * 1.1.0-1 (release/next)
     | |
     |/
     * 1.0.1 (main)
     |
     * (tag: 1.0.0)

Scenario 2:

• main branch with is-mainline true and patch increment
• release branch with is-mainline true and minor increment

       * 1.3.0 -> e.g. do a fast-forward merge to main and tag it with 1.3.0
       |
       * 1.2.0 (release/next)
       |
      /
     * 1.0.1 (main)
     |
     * (tag: 1.0.0)