[Feature] Patch version not incrementing based on commit message

[andreear-23]

Describe the bug
It seems the patch version does not increment properly based on commit message keywords. It seemed to work when I tested it last month but now I'm having some issues with this.

Expected Behavior

Doing a commit with the keywords +semver:fix additional text or +semver:patch additional text should increase the patch version.

For example the current gitversion is 1.0.1-dev.19, I do a git commit --allow-empty -m "added a fix for bug +semver:fix"

I expect the next gitversion to be 1.0.2-dev.20.

Actual Behavior

Following the example from above, the actual gitversion generates: 1.0.1-dev.20

Context

I am trying to use gitversion for setting the version of a pip library automatically. Initially when I tested it I had some issues with incrementing the patch value that went away after I removed the next-version flag from GitVersion.yml.

Furthermore I had issues due to some existing incompatibilities between gitversion and PEP440 specification so I needed to tweak the tags that get generated by gitversion. Finally I decided to just use the Major.Minor.Patch version so there are no more complications.

I added a tag v1.0.0 on my feature branch that introduced support for gitversion such that all future versions are computed from that.
So now my devel branch has gitversion: 1.0.1.
I want to merge in a feature branch that adds some additional scripts and I added in one of the commit messages +semver:fix but it did not change the Patch value.

Maybe I am misunderstanding the way the keywords in commit messages are impacting the generated SemVer but my impression is that if I have a feature branch that starts at version 1.0.1 and I do 3 commits and 2 of those commits contain the +semver: fix keyword, the version I should get when I merge the PR into devel should be at least 1.0.3.

Your Environment

Using unix-based environment, however gitversion tool is running inside a docker container.
Version of gitversion /version: 5.10.3+Branch.support-5.x.Sha.bc9c9d003e655385e3dd1ba3bd013e04062d2f9b

• Version Used: Using Ubuntu 20.04 for development, the docker image is based also on Ubuntu 20.04.4 LTS.

My GitVersion.yml file looks like this:

mode: Mainline
commit-message-incrementing: Enabled
major-version-bump-message: '\+semver:\s?(breaking|major)'
minor-version-bump-message: '\+semver:\s?(feature|minor)'
patch-version-bump-message: '\+semver:\s?(fix|patch)'
branches:
  master:
    regex: ^master$|^main$
    tag: ''
  release:
    tag: 'rc'
  feature:
    tag: 'a'
    regex: ^feature[/]
  develop:
    regex: ^dev(el)?(op)?(ment)?$
    tag: 'dev'
  hotfix:
    tag: 'post'
    regex: ^hotfix|^bugfix
ignore:
  sha: []
merge-message-formats: {}
 

[HHobeck]

#3097 (comment)

AFAIK this is expected behavior. If your release has multiple features you don't increment the minor N times for every feature, you increment it once. If you want to increment the minor version again, you need to tell it that it is the next release by tagging with 1.5.0

I think for trunk based (also known as main line) scenarios the behavior of incrementing only one time makes no sense. It might be a option to change this constraint for mainline mode. @asbjornu What do you think?

[asbjornu]

As I don't use mainline mode myself, I don't really know what people expect here. Some seem to expect that commit message incrementation coalesces and some that they add up. I have no idea what's "right".

For now, I think we should do as I write in #3097 (comment) and document the current behavior better. The next step would be to consider either changing the behavior depending on the chosen mode, or to introduce a separate configuration for this.

If we allow this behavior to be configured, we can either use the existing commit-message-incrementing and expand the enum from [Disabled, Enabled] to something like [Disabled, Enabled, Coalesce, Sum, or introduce a new property, such as commit-message-incrementing-behavior: Coalesce | Sum.

All names are of course open for debate, these are just the first that came to my head. Thoughts?

[wmclifford]

FWIW and simply as an example of a similar tool, there is a Gradle plugin for SemVer calculation which provides both options (coalesce and sum), which is controlled by a property in the build file. The default is to coalesce so that multiple feature/patch commits only increment the minor/patch by 1. Personally, I believe this to be the majority use case as, IMO, it makes the most sense. However, I can certainly see cases where each feature or fix commit could warrant an increment in the version numbers. Having the ability to do either is certainly a worthwhile addition, and clearly document what the default option would be. The [Disabled, Enabled, Coalesce, Sum] update looks like a very good choice and should be easy enough for the community to adopt. All I would say there is that Enabled can either be omitted and either Coalesce or Sum be required (as it would imply the option is enabled), or that it mean that the option is enabled with the default setting.

[HHobeck]

As I don't use mainline mode myself, I don't really know what people expect here. Some seem to expect that commit message incrementation coalesces and some that they add up. I have no idea what's "right".

For now, I think we should do as I write in #3097 (comment) and document the current behavior better. The next step would be to consider either changing the behavior depending on the chosen mode, or to introduce a separate configuration for this.

If we allow this behavior to be configured, we can either use the existing commit-message-incrementing and expand the enum from [Disabled, Enabled] to something like [Disabled, Enabled, Coalesce, Sum, or introduce a new property, such as commit-message-incrementing-behavior: Coalesce | Sum.

All names are of course open for debate, these are just the first that came to my head. Thoughts?

Okay good idea to make it configurable. Then I change this issue from bug to feature and move it to the milestone 7.x.

[andreear-23]

Hey guys, thanks for all the answers. However what I am confused about is that nothing gets incremented at all. I'm not talking about multiple increments of the Patch version for the same feature branch, for me it does not increment it even once.
My original post contains a configuration that I was testing out trying to see if I can get the behaviour I wanted. However, this is the currently used GitVersion.yml:

branches:
  master:
    regex: ^master$|^main$
    tag: ''
  release:
    tag: 'rc'
  feature:
    tag: 'a'
    regex: ^feature[/]
  develop:
    regex: ^dev(el)?(op)?(ment)?$
    tag: 'dev'
  hotfix:
    tag: 'post'
    regex: ^hotfix|^bugfix
ignore:
  sha: []
merge-message-formats: {}

Looking at the documentation, ContinuousDelivery seems to be the default versioning mode used, so basically the versions are only computed using tags if I understand correctly.
So when I added support for gitversion to the repo, I added a tag : v1.0.0 to the feature branch and pushed it, then I merged that feature branch into devel. Then I noticed that our CI generates version v.1.1.0 for the devel branch after merging - that's still fine.

However now I created a feature branch, added some changes and merged it to devel (without creating a tag nor using the +semver keyword in any commits in the feature branch) . The problem is that the CI tries to build a library with the same version v1.1.0 which will fail because we cannot override existing pip wheels.
So what am I doing wrong and is there a way of getting the versioning that I want? Shortly put, I want to get a different version on devel after any PR gets merged into the branch.
Thanks!

[HHobeck]

Please try the latest development stage (master branch) and let me know if this behavior still persists. In advance please provide an integration test for your scenario like:

    [Test]
    public void ShouldProvideTheCorrectVersionEvenIfPreReleaseLabelExistsInTheGitTagMain()
    {
        var configuration = GitFlowConfigurationBuilder.New
            .WithNextVersion("5.0")
            .WithSemanticVersionFormat(SemanticVersionFormat.Loose)
            .WithBranch("main", _ => _
                .WithLabel("beta")
                .WithIncrement(IncrementStrategy.Patch)
                .WithVersioningMode(VersioningMode.ContinuousDeployment)
                .WithIsMainline(false)
            ).Build();

        using EmptyRepositoryFixture fixture = new("main");
        fixture.MakeACommit();

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

        fixture.MakeACommit();

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

        fixture.ApplyTag("5.0.0-beta.3");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("5.0.0-beta.3", configuration);

        fixture.MakeATaggedCommit("5.0.0-rc.1");

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

        fixture.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("5.0.0-beta.5", configuration);
    }

If you not fimiliar with it please use the released version 6.0.0-beta.2 (keep in mind that the configuration has been changed) and provide exactly the steps to reproduce (git commands?). Thank you very much.

[andreear-23]

I am not familiar with the testing framework, how do I import the necessary namespaces? I installed the tool in a docker image like so:
/usr/share/dotnet/dotnet tool install --global GitVersion.Tool --version 6.0.0-beta.2
After generating a template test and adding the code snippet you shared, running the tests gives the following error:

/workspace/gitversion_tests_v2/UnitTest1.cs(20,29): error CS0103: The name 'GitFlowConfigurationBuilder' does not exist in the current context [/workspace/gitversion_tests_v2/GitVersionTest.csproj]
/workspace/gitversion_tests_v2/UnitTest1.cs(22,40): error CS0103: The name 'SemanticVersionFormat' does not exist in the current context [/workspace/gitversion_tests_v2/GitVersionTest.csproj]
/workspace/gitversion_tests_v2/UnitTest1.cs(30,15): error CS0246: The type or namespace name 'EmptyRepositoryFixture' could not be found (are you missing a using directive or an assembly reference?) [/workspace/gitversion_tests_v2/GitVersionTest.csproj]

Thank you!