Help applying flow

[facusantillo]

If this is a bug please tell me and I'll report it.

Testing version 6.0.0-beta.2 I'm not achieving the flow I'm looking for, it goes as follows:

ITERATION I:

develop has tag 1.0.0
feature/minor_bump_1 merges into develop generating version 1.1.0-rc.1
feature/minor_bump_2 merges into develop generating version 1.1.0-rc.2
version 1.1.0-rc.2 it's released to production, so we tag develop as 1.1.0

ITERATION II:
develop has tag 1.1.0
feature/minor_bump_3 merges into develop generating version 1.2.0-rc.1 (so far so good)
a bug is encountered in prod version 1.1.0 (aka 1.1.0-rc.2).
a branch is created to fix the bug from that tag, therefore: release/1.1.0_fixes
hotfix/fix_1 merges into release/1.1.0_fixes generating version 1.1.0-rc.3 (this is the unwanted behavior)

I want the hotfix to generate version 1.1.1-rc.1 because it's configured as patch, but somehow when the pull request is merged, the calculated version is finally 1.1.0-rc.3 (it's not taking into consideration the increment: Patch on release branch)

How can this be achieved? What I'm doing wrong?

This is my gitversion file:

mode: ContinuousDelivery
commit-message-incrementing: enabled

branches:
  release:
    mode: ContinuousDelivery
    regex: ^release?
    label: 'rc'
    increment: Patch
    prevent-increment-of-merged-branch-version: false
    tracks-release-branches: false
    track-merge-target: false
    source-branches:
      - develop
      - hotfix
    is-release-branch: true
    is-mainline: false

  develop:
    mode: ContinuousDelivery
    regex: ^develop$
    prevent-increment-of-merged-branch-version: true
    label: 'rc'
    tracks-release-branches: false
    track-merge-target: true
    increment: Minor
    is-release-branch: false
    is-mainline: true
    source-branches: []
    pre-release-weight: 60000

  hotfix:
    mode: ContinuousDelivery
    regex: ^hotfix?
    prevent-increment-of-merged-branch-version: false
    label: hotfix
    tracks-release-branches: true
    track-merge-target: true
    increment: Patch
    is-release-branch: false
    is-mainline: false    
    source-branches:
      - main
      - release
    pre-release-weight: 30000

  pull-request:
    mode: ContinuousDeployment
    label: 'PR'
    increment: Inherit
    regex: ^pull?
    is-release-branch: false
    prevent-increment-of-merged-branch-version: false
    is-mainline: false
    tracks-release-branches: false
    track-merge-target: false
    source-branches:
      - feature
      - hotfix
      - develop
      - release
    pre-release-weight: 30000
    
  feature:
    mode: ContinuousDelivery
    label: 'rc'
    increment: Inherit
    regex: ^feature?
    is-release-branch: false
    prevent-increment-of-merged-branch-version: false
    is-mainline: false
    tracks-release-branches: false
    track-merge-target: true
    source-branches:
      - feature
      - hotfix
      - develop
      - release
    pre-release-weight: 30000

The CI platform used is Azure Pipelines

[arturcic]

@HHobeck

[facusantillo]

I have managed to achieve but not sure if this is the correct configuration:

mode: ContinuousDelivery
commit-message-incrementing: enabled

branches:
  release:
    mode: ContinuousDelivery
    regex: ^release?
    label: 'rc'
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    tracks-release-branches: true
    track-merge-target: true
    source-branches:
      - develop
      - hotfix
    is-release-branch: true
    is-mainline: false

  develop:
    mode: ContinuousDelivery
    regex: ^develop$
    prevent-increment-of-merged-branch-version: true
    label: 'rc'
    tracks-release-branches: true
    track-merge-target: true
    increment: Minor
    is-release-branch: false
    is-mainline: true
    source-branches: []
    pre-release-weight: 60000

  hotfix:
    mode: ContinuousDelivery
    regex: ^hotfix?
    prevent-increment-of-merged-branch-version: false
    label: hotfix
    tracks-release-branches: true
    track-merge-target: true
    increment: Patch
    is-release-branch: false
    is-mainline: false    
    source-branches:
      - main
      - release
    pre-release-weight: 30000

  pull-request:
    mode: ContinuousDeployment
    label: 'PR'
    increment: Inherit
    regex: ^pull?
    is-release-branch: false
    prevent-increment-of-merged-branch-version: false
    is-mainline: false
    tracks-release-branches: true
    track-merge-target: true
    source-branches:
      - feature
      - hotfix
      - develop
      - release
    pre-release-weight: 30000
    
  feature:
    mode: ContinuousDelivery
    label: 'rc'
    increment: Inherit
    regex: ^feature?
    is-release-branch: false
    prevent-increment-of-merged-branch-version: false
    is-mainline: false
    tracks-release-branches: true
    track-merge-target: true
    source-branches:
      - feature
      - hotfix
      - develop
      - release
    pre-release-weight: 30000

I switched the following props to true:

tracks-release-branches: true
track-merge-target: true

[HHobeck]

Actually it's quite hard to answer the question: Is the configuration correct or not without knowing the branching and merge strategy. I would suggest you to use the existing git-hub workflow and adapt it for your needs. Please see the following activity diagrams: https://gitversion.net/docs/learn/branching-strategies/gitflow/examples

[facusantillo]

I have tested it with the flags and it's working.

What exactly are those flags doing?

tracks-release-branches: true
track-merge-target: true

[HHobeck]

I have tested it with the flags and it's working.

What exactly are those flags doing?

tracks-release-branches: true
track-merge-target: true

track-merge-target

Strategy which will look for tagged merge commits directly off the current
branch. For example develop → release/1.0.0 → merge into main and tag
1.0.0. The tag is not on develop, but develop should be version 1.0.0 now.

track-merge-message

This property is a branch related property and gives the user the possibility to control the behavior of whether the merge
commit message will be interpreted as a next version or not. Consider we have a main branch and a release/1.0.0 branch and
merge changes from release/1.0.0 to the main branch. If track-merge-message is set to true then the next version will
be 1.0.0 otherwise 0.0.1.

tracks-release-branches

Indicates this branch config represents develop in GitFlow.

Indeed the documentation of tracks-release-branches is not so well but you can think of that if you set it to true the branch version of release branches (and hotfix branches bescause is-release = true) will be determined and used as a base version for the current branch.

[facusantillo]

Ok, it's a bit confusing but I think I got it. We are using trunk based so we don't have main and develop, just develop.

We use continuous delivery mode with feature branches so whenever a feature branch is merged into develop we bump the revision number, ie:

PR1 => 1.0.0-rc.1
PR2 => 1.0.0-rc.2
PR3 => 1.0.0-rc.3 (and so...)

When a given version is mature enough to move to prod (let's say 1.0.0-rc.3) we close the release by tagging in that commit the 1.0.0 version.

Now we start developing the next version and GitVersion will bump to 1.1.0 accordingly:
PR1 => 1.1.0-rc.1
PR2 => 1.1.0-rc.2
PR3 => 1.1.0-rc.3 (and so...)

The problem is when you found a bug on prod and you need to create a release branch to start fixing the bug because it's not really bumping the patch version. Based on what you have pointed on the documentation if we set those flags to true, then we can discover the tags on other branches, therefore will calculate as expected.

Hope this clarifies the flow

[HHobeck]

Why not like this?

[Test]
public void __Just_A_Test__()
{
    var configuration = GitFlowConfigurationBuilder.New
        .WithBranch("main", _ => _.WithIncrement(IncrementStrategy.Minor))
        .WithBranch("hotfix", _ => _.WithIncrement(IncrementStrategy.Patch))
        .Build();

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

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

    fixture.BranchTo("feature/minor_bump_1");
    fixture.MakeACommit();

    // ✅ succeeds as expected
    fixture.AssertFullSemver("1.1.0-minor-bump-1.1+1", configuration);

    fixture.Checkout("main");
    fixture.MergeNoFF("feature/minor_bump_1");
    fixture.Repository.Branches.Remove("feature/minor_bump_1");

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

    fixture.BranchTo("feature/minor_bump_2");
    fixture.MakeACommit();

    // ✅ succeeds as expected
    fixture.AssertFullSemver("1.1.0-minor-bump-2.1+3", configuration);

    fixture.Checkout("main");
    fixture.MergeNoFF("feature/minor_bump_2");
    fixture.Repository.Branches.Remove("feature/minor_bump_2");

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

    fixture.ApplyTag("1.1.0");
    var commit = fixture.Repository.Head.Tip;
    fixture.BranchTo("feature/minor_bump_3");
    fixture.MakeACommit();

    // ✅ succeeds as expected
    fixture.AssertFullSemver("1.2.0-minor-bump-3.1+1", configuration);

    fixture.Checkout("main");
    fixture.MergeNoFF("feature/minor_bump_3");
    fixture.Repository.Branches.Remove("feature/minor_bump_3");

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

    Commands.Checkout(fixture.Repository, commit);
    fixture.BranchTo("hotfix/1.1.1");
    fixture.MakeACommit();

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

    fixture.Checkout("main");
    fixture.MergeNoFF("hotfix/1.1.1");
    fixture.Repository.Branches.Remove("hotfix/1.1.1");

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