Mainline Not Incrementing SemVer when merging to main with AzureDevops

[tfendt-belong-gg]

I'm trying to setup GitVersion and running in to an issue with generating the correct SemVer values. It is possible I just don't understand how it is supposed to work as I am new to this tool.

Here are the steps I took:

• Added a version tag to the Main branch (1.0.5)
• Created a new feature branch from main (feature/azure-devops)
• Merged the feature branch to main

When calculating the version for the feature branch it looks correct. I get a version of 1.0.5-azure-devops.10
After merging the feature branch to main the calculated version is 1.0.5 and it should be 1.0.6 or rather 1.1.0 since this was a feature branch.

Here is my config:

next-version: 1.0
mode: Mainline
increment: Inherit
update-build-number: true
branches:
  main:
    regex: ^main$
    is-mainline: true

Here are the logs for the run after merging the feature branch to main:

INFO [01/04/22 17:56:51:81] Begin: Calculating base versions
    INFO [01/04/22 17:56:51:83] NextVersion in GitVersion configuration file: 1.0.0 with commit count source External Source
    INFO [01/04/22 17:56:51:85] Fallback base version: 0.1.0 with commit count source 94f8b33052712e905160b3056
    INFO [01/04/22 17:56:51:88] Git tag 'v1.0.5': 1.0.5 with commit count source a4b457d1029cb00d01adc
    INFO [01/04/22 17:56:51:88] Git tag 'v1.0.4.2': 1.0.4+2 with commit count source 5e1e5937323357620da2db3afcdd
    INFO [01/04/22 17:56:51:92] Found multiple base versions which will produce the same SemVer (1.0.6), taking oldest source for commit counting (Git tag 'v1.0.5')
    INFO [01/04/22 17:56:51:92] Base version used: Git tag 'v1.0.5': 1.0.5 with commit count source a4b457d1029cb00d01adc
  INFO [01/04/22 17:56:51:92] End: Calculating base versions (Took: 111.30ms)
  INFO [01/04/22 17:56:51:92] 2 commits found between a4b457d Merge branch 'feature/azure-devops' into 'main' and 01649a5 Merge branch 'feature/azure-devops' into 'main'
  INFO [01/04/22 17:56:51:93] Begin: Using mainline development mode to calculate current version
    INFO [01/04/22 17:56:51:94] Found possible mainline branches: main
    INFO [01/04/22 17:56:51:94] Mainline for current branch is main
    INFO [01/04/22 17:56:51:94] 2 commits found between a4b457d Merge branch 'feature/azure-devops' into 'main' and 01649a5 Merge branch 'feature/azure-devops' into 'main'
  INFO [01/04/22 17:56:51:94] End: Using mainline development mode to calculate current version (Took: 16.99ms)
  INFO [01/04/22 17:56:51:95] Begin: Creating dictionary
  INFO [01/04/22 17:56:51:95] End: Creating dictionary (Took: 4.89ms)
  INFO [01/04/22 17:56:51:95] Begin: Storing version variables to cache file D:\a\1\s\.git\gitversion_cache\9506D992C48C14BD0BC2C0F585BFC5F2F0AA2B5B.yml
  INFO [01/04/22 17:56:51:99] End: Storing version variables to cache file D:\a\1\s\.git\gitversion_cache\9506D992C48C14BD0BC2C0F585BFC5F2F0AA2B5B.yml (Took: 39.91ms)
Executing GenerateSetVersionMessage for 'AzurePipelines'.
Executing GenerateBuildLogOutput for 'AzurePipelines'.
{
  "Major": 1,
  "Minor": 0,
  "Patch": 5,
  "PreReleaseTag": "2",
  "PreReleaseTagWithDash": "",
  "PreReleaseLabel": "",
  "PreReleaseLabelWithDash": "",
  "PreReleaseNumber": null,
  "WeightedPreReleaseNumber": 60000,
  "BuildMetaData": null,
  "BuildMetaDataPadded": "",
  "FullBuildMetaData": "Branch.main.Sha.01649a5c492989d099a45ea0ddbc",
  "MajorMinorPatch": "1.0.5",
  "SemVer": "1.0.5",
  "LegacySemVer": "1.0.5",
  "LegacySemVerPadded": "1.0.5",
  "AssemblySemVer": "1.0.5.0",
  "AssemblySemFileVer": "1.0.5.0",
  "FullSemVer": "1.0.5",
  "InformationalVersion": "1.0.5+Branch.main.Sha.01649a5c492989d099a45ea0ddbc",
  "BranchName": "main",
  "EscapedBranchName": "main",
  "Sha": "01649a5c492989d099a45ea0ddbc",
  "ShortSha": "01649a5",
  "NuGetVersionV2": "1.0.5",
  "NuGetVersion": "1.0.5",
  "NuGetPreReleaseTagV2": "",
  "NuGetPreReleaseTag": "",
  "VersionSourceSha": "a4b457d1029cb00d01adc",
  "CommitsSinceVersionSource": 2,
  "CommitsSinceVersionSourcePadded": "0002",
  "UncommittedChanges": 0,
  "CommitDate": "2022-01-04"
}

[tfendt-belong-gg]

I found that removing the next-version: 1.0 line results in updating the version number. However it is only updating the patch version. Shouldn't it update the minor version since this was a feature branch that was merged?

[tfendt-belong-gg]

Figured it out. Have to explicitly define those rules.

mode: Mainline
increment: Inherit
update-build-number: true
branches:
  main:
    regex: ^main$
    is-mainline: true
  feature:
    regex: ^features?[/-]
    tag: useBranchName
    increment: Minor
  hotfix:
    regex: ^(bugfix|hotfix(es)?)[/-]
    tag: useBranchName
    increment: Patch

[HippyRock]

Hi folks, I'm struggling as well with auto incrementing 'Minor' version on my Mainline when feature branch gets merged into Master. This is what I see:

• starting point of main line: 1.1.1
• feature branch created: 1.2.0-feature-0
• feature branch changed: 1.2.0-feature-1
• feature branch merged to master: 1.1.2. But why? I expect mainline to be 1.2.0 here.

I'm using GitVersion.Tool 5.11.1 x64
Maybe I'm missing something, please let me know, this is my GitVersion configuration:

mode: Mainline
increment: Inherit
update-build-number: true
branches:
  bugfix:
    increment: Patch
    source-branches: ['master']
    regex: bugfix?[/-]
    tag: useBranchName
  feature:
    increment: Minor
    regex: feature?[/-]
    source-branches: ['master']
    tag: useBranchName
  master:
    is-mainline: true
    regex: master$
    is-source-branch-for: ['bugfix', 'feature']

PS: This might be related: #1221 or #2870

[HHobeck]

Hi folks, I'm struggling as well with auto incrementing 'Minor' version on my Mainline when feature branch gets merged into Master. This is what I see:

• starting point of main line: 1.1.1
• feature branch created: 1.2.0-feature-0
• feature branch changed: 1.2.0-feature-1
• feature branch merged to master: 1.1.2. But why? I expect mainline to be 1.2.0 here.

I'm using GitVersion.Tool 5.11.1 x64 Maybe I'm missing something, please let me know, this is my GitVersion configuration:

mode: Mainline
increment: Inherit
update-build-number: true
branches:
  bugfix:
    increment: Patch
    source-branches: ['master']
    regex: bugfix?[/-]
    tag: useBranchName
  feature:
    increment: Minor
    regex: feature?[/-]
    source-branches: ['master']
    tag: useBranchName
  master:
    is-mainline: true
    regex: master$
    is-source-branch-for: ['bugfix', 'feature']

PS: This might be related: #1221 or #2870

The main line mode only says that it is incrementing every time you are placing a commit. But how the version will be incremented dependents on:

1. the increment strategy on the main branch (In your scenario defaults to PATCH)
2. the usage of bump messages
3. and more

** I need to revise my statement. The mainline mode has a special logic to determine the increment strategy which is dependent on the following rules:

1. the usage of bump messages in the commits since last fork
2. the existent of a merge message to identify the source increment strategy
3. the increment strategy on the main branch
4. fallback to patch strategy

I cannot explain you why your scenario is not working because I don't know your workflow. Every person has a different expectation so we need to agree first on one or another workflow. Two known workflows are GitFlow and GitHub workflow which are very sophisticated and very good documented.

At the beginning I would like to ask you to take a look on this two workflows and then mastering it with main line mode. I can guide you to the following examples which are explaining the GitFlow and GitHub workflows very well: https://gitversion.net/docs/learn/branching-strategies/gitflow/examples

[HippyRock]

@HHobeck thanks you for the feedback! I guess I just need to clarify if GitVersion be configured to automatically increment 'Minor' version when merge happens from feature branches. This one is related: #3114

I'm just trying to avoid manual version bumping with +semver:minor and +semver:patch commit messages. This would duplicate information since we already decided how to increment the number when we decided how to name our branch. Furthermore, commit message are often forgotten or used too often. We therefore don't want to rely on them and rely on something more simple: the branch name. In general, this is our flow:

---

When a developer starts to work on something, he knows if he is working on a bug fix or a new feature. He therefore pulls the master branch to have the latest version and creates a branch from master. For a feature branch, he has to start the branch name by features/ and for a bug fix by bugfix/. He codes in that branch. Once he's done, he opens a pull request which gets built and reviewed. Once everything is approved and the code is ready to go to production, the pull request is accepted.

At this point, here is how we expect GitVersion to behave for the numbering of the master branch:

when it detects that a feature branch (i.e. a branch starting by features/) was merged, it should automatically increment the Minor number.
when it detects that a bug fix branch (i.e. a branch starting by bugfixes/) was merged, it should automatically increment the Patch number.

Thanks!

[HippyRock]

I ran this test on the latest from master

    [Test]
    public void MergeFeatureIntoMainlineWithMinorIncrement2()
    {
        var configuration = new GitVersionConfiguration
        {
            VersioningMode = VersioningMode.Mainline,
            Branches = new Dictionary<string, BranchConfiguration>
            {
                { "feature", new BranchConfiguration { Increment = IncrementStrategy.Minor } }
            },
            Ignore = new IgnoreConfiguration { Shas = new List<string>() },
            MergeMessageFormats = new Dictionary<string, string>()
        };

        using var fixture = new EmptyRepositoryFixture();
        fixture.MakeACommit();
        fixture.ApplyTag("1.0.0");
        fixture.AssertFullSemver("1.0.0", configuration);

        fixture.BranchTo("feature/foo");
        fixture.MakeACommit();
        fixture.AssertFullSemver("1.1.0-foo.1", configuration);

        fixture.Checkout(MainBranch);
        fixture.MergeNoFF("feature/foo");
        fixture.AssertFullSemver("1.1.0", configuration);
    }

Can someone explain me why in the test mainline gets bumped to '1.1.0' after feature merge with increment=Minor, but if I try to repeat the same test on real repository only Patch version gets bumped for the Mainline?

mode: Mainline
branches:
  feature:
    regex: feature?[/-]
    increment: Minor
ignore:
  sha: []
merge-message-formats: {}

[HHobeck]

** I need to revise my statement. The mainline mode has a special logic to determine the increment strategy which is dependent on the following rules:

1. the usage of bump messages in the commits since last fork
2. the existent of a merge message to identify the source increment strategy
3. the increment strategy on the main branch
4. fallback to patch strategy

I'm not using the mainline mode by myselfe. But I have taken a look into the code and it seems to be working like you would expecting it:

[HHobeck]

Can someone explain me why in the test mainline gets bumped to '1.1.0' after feature merge with increment=Minor, but if I try to repeat the same test on real repository only Patch version gets bumped for the Mainline?

I know that AzureDevops generates different merge messages compared to git (when using the build in PR mechanism). The information about the source branch are not part of the message and thus gets lost. That might be the reason.

[HippyRock]

@HHobeck
I think I found a difference, for Azure DevOps commit.Parents is always 0 (MainlineVersionCalculator.cs):

so AggregateMergeCommitIncrement is ever gets called. I will dig more to see why is that so. But if you have any ideas where to look next please let me know. Thanks!

[HHobeck]

It is very hard for me to analyse your issue without any steps to reproduce. The only thing I can do is speculating: In my opinion it has something to do with how you are using AzureDevops. If you are finalize your PR you have different options like:

• Merge (no fast forward)
• Squash commit
• Rebase and fast-forward
• Semi-linear merge

You need to select the first option and provide a customized merge message in the correct format if you ask me.

[jpodoba]

Hi, @HHobeck I got the same issue. The changes merged locally with the commands below work as expected but when I execute the same via Azure DevOps and PR to the main branch always PATCH is incremented. I've tried different versions of gitversion and all kinds of merge types. Have you solved that by that customize message?

`git branch

• main

gitversion /showvariable SemVer
0.7.0

git checkout -b feature/test1

git commit -m "test commit 1" --allow-empty
git commit -m "test commit 2" --allow-empty
git commit -m "test commit 3" --allow-empty

git checkout main

git merge --no-ff feature/test1

gitversion /showvariable SemVer
0.8.0`

[jpodoba]

Hi, @HHobeck I got the same issue. The changes merged locally with the commands below work as expected but when I execute the same via Azure DevOps and PR to the main branch always PATCH is incremented. I've tried different versions of gitversion and all kinds of merge types.

git branch
* main

gitversion  /showvariable SemVer
0.7.0

git checkout -b feature/test1

git commit -m "test commit 1" --allow-empty
git commit -m "test commit 2" --allow-empty
git commit -m "test commit 3" --allow-empty

git checkout main

git merge --no-ff feature/test1

gitversion  /showvariable SemVer
0.8.0

[HHobeck]

If you have trouble with AzureDevops I would recommend you to take a look how the branch history looks like and answering the question: What is the difference between the history of AzureDevops compared to the history of native git?

Like I already mentioned:

In my opinion it has something to do with how you are using AzureDevops.

[HHobeck]

Please see following issues on visualstudio.com:

• Customizable templates for the default merge commit message
• Change default title for pull request commits to not include PR id

[jpodoba]

Yes I saw it, testing right now

[jpodoba]

The best for me fit the solution with pull_request template messages. It's not ideal because requires additional effort and updates each repo but works with squash merges and Mainline mode used in our approach.

That was described here if someone will need it.