[Bug] 'Increment: Minor' config does not work. Patch is only ever incremented

[danijam]

Describe the bug
I'm struggling to control the behaviour of GitVersion with respect to incrementing different parts of the version number. It appears to me that the configuration option named increment does not do anything. I'm wondering if I am using GitVersion entirely wrongly, would appreciate some feedback on the below.

Expected Behavior

I expect every commit to main will increment minor.

Actual Behavior

Every commit to main increments patch

Steps to Reproduce

GitVersion.yml

next-version: 0.0
assembly-versioning-scheme: Major
assembly-file-versioning-scheme: MajorMinorPatchTag
mode: ContinuousDeployment
continuous-delivery-fallback-tag: ''
increment: Minor

1. Tag the head of main with a version such as 0.1.0
2. Commit a new commit to main
3. Run GitVersion

Context

Flow is in essence each contributor opens a branch off main, creates commits. opens PR. PR is squashed merged into main. the new build of that new commit in main should be built incrementing minor unless the major bump message is included.

Lets say I have this under git log --oneline

46ee618 (HEAD -> main) Commit 2
f6b2a66 (tag: 0.1.0) Commit 1

GitVersion wants the version of Commit 2 to be 0.1.1. I don't understand why when my config is set to increment minor.

Each commit on main should increment minor as this is a continuos deployment repo for a NuGet library. patch increments are controlled through hotfix branches and major increments are controlled through commit messages. So the default increment is minor. I've been banging my head against the wall struggling to find how to use GitVersion?

Your Environment

This can be reproduced on any environment. My test environment is just a sample empty git repo for testing GitVersion out for now.

• Version Used: 5.7.0
• Operating System and version (Windows 10, Ubuntu 18.04): Win 10

[danijam]

So turns out the increment: minor config line at the global level indeed doesn't seem to have any impact. I pushed that setting down into a branch specific block and then started working. I can't confirm if this is a bug or intended behaviour so will leave this open.

[asbjornu]

This does feel like a bug to me. However, changing the behaviour could be seen as a breaking change, although one that should be easy enough to remedy (remove the global increment: property). It would be interesting to see whether a PR fixing this also broke any other tests or not.

[mdg215199]

After updating, when I merge my develop branch to master, my develop branch goes back to the same version every time now.

Example:
next-version: 9.0.1
mode: Mainline
branches: 
  master:  
    regex: master
    increment: minor
  develop:
    tag: 'pre-release'
    regex: develop
    increment: patch
ignore:
  sha: []
merge-message-formats: {}

Patch increments when committed in develop, but once I merge from develop -> master, develop clears patch back to beginning, but doesnt increment the minor, so I get stuck in 9.0.1-pre-relase.1.

[asbjornu]

@mdg215199, Try deleting the next-version key.

[guifran001]

The branch workaround works:

branches: 
  main:  
    regex: .*
    source-branches: [main]
    increment: minor

But the real fix should be to change this line:

GitVersion/src/GitVersion.Core/VersionCalculation/MainlineVersionCalculator.cs

Line 325 in 3f633ca

return VersionField.Patch;

for something that would use the context.IncrementStrategy

something like (I'm not good in C#)

return ToVersionField(IncrementStrategy ?? IncrementStrategy.Patch);

Sorry, I'm not set to develop in C# right now, so I don't think I will open a pr.

[HippyRock]

Folks, please take a look on my my post here Bottom like I'm struggling with auto incrementing 'Minor' version on the Mainline when feature branch gets merged into Master. Thanks!

[HHobeck]

I have executed the following integration test succesfully on the current main branch:

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

    using var fixture = new EmptyRepositoryFixture("main");

    fixture.MakeATaggedCommit("1.1.30");
    fixture.MakeACommit();
    fixture.MakeACommit();

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

On the root configuration layer we have some branch related properties which are only applying as a fallback. In the breaking change documentation the behavior is explained as following:

• The fallback version strategy now returns 0.0.0 and is flagged with ShouldIncrement equal to true. This yields the version 0.1.0 on the develop branch (IncrementStrategy.Minor by default) and 0.0.1 on the main branch (IncremetnStrategy.Patch by default).
• Additional fallback branch configuration properties have been introduced at the root to define base properties which will be inherit to the branch configurations. That means if no other branch configuration in the inheritance line defines the given property the fallback property applies. Notice that the inheritance tree can be controlled using the increment strategy property in the branch configuration section.
  • The following example illustrates this behavior. The hotfix branch configuration overrides the main branch configuration and the result overrides the fallback branch configuration.

  * 1f1cfb4 52 minutes ago  (HEAD -> hotfix/just-a-test)
  * 14800ff 58 minutes ago  (tag: 1.0.0, main)