[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!

[HHobeck]

Hi there.

If you want to execute or create new integration tests please download the source code and build the source: https://github.com/GitTools/GitVersion/releases/tag/6.0.0-beta.2

You will find the tests in GitVersion.Core.Tests project.

[andreear-23]

Hi, I managed to build and execute some tests, especially the one you shared above. The test passes however that still does not offer more clarity as to why I cannot increase the patch version of the main branch by merging in a branch that increases the patch version via the commit message.
This is a snippet of the test I wrote trying to understand better the behaviour of gitversion:

        var configuration = GitFlowConfigurationBuilder.New
            .WithNextVersion("1.0.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("1.0.0-beta.1", configuration);

        fixture.MakeACommit();

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

        fixture.ApplyTag("1.1.0");

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

        fixture.MakeACommit("testing +semver: fix");

        fixture.AssertFullSemver("1.1.1-beta.1", configuration);

        fixture.CreateBranch("feature/add_scripts");

        fixture.MakeACommit("Adding my scripts, +semver:patch");

        fixture.Checkout("main");

        fixture.MergeNoFF("feature/add_scripts");
    
        fixture.AssertFullSemver("1.1.2-beta.1", configuration);  <------ this fails

Also with this different configuration:

 var configuration = GitFlowConfigurationBuilder.New
            .WithNextVersion("1.0.0")
            .WithSemanticVersionFormat(SemanticVersionFormat.Loose)
            .WithCommitMessageIncrementing(CommitMessageIncrementMode.Enabled)
            .WithBranch("main", _ => _
                .WithLabel("beta")
                .WithVersioningMode(VersioningMode.Mainline)
            ).Build();

My test fails with the following asserts:

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

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

        fixture.MakeACommit();

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

        fixture.ApplyTag("1.1.0");

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

        fixture.MakeACommit("testing +semver: fix");
        // ---> fails <----
       // should be "1.1.1-beta.1" but was "1.1.0-beta.1"
        fixture.AssertFullSemver("1.1.1-beta.1", configuration); 

        fixture.CreateBranch("feature/add_scripts");

        fixture.MakeACommit("Adding my scripts, +semver:patch");

        fixture.Checkout("main");

        fixture.MergeNoFF("feature/add_scripts");
         // ---> fails <----
        fixture.AssertFullSemver("1.1.2-beta.2", configuration);

[HHobeck]

To your first unit test I can say it has been already answered: see #3097 (comment) and the comments above.

[HHobeck]

To the second unit test: If you use bump messages then it's better to not use next-version at least for mainline mode (I think it is a bug in the implementation). In advance I'm not sure if the usage of pre-release label on a mainline branch makes sense. I thougth mainline alias trunkbased workflow not using tags at all?

Please try this:

    [Test]
    public void __Just_A_Test__()
    {
        var configuration = GitFlowConfigurationBuilder.New
            //.WithNextVersion("1.0.0") // <<-- This does not play well with bump messages
            .WithSemanticVersionFormat(SemanticVersionFormat.Loose)
            .WithCommitMessageIncrementing(CommitMessageIncrementMode.Enabled)
            .WithBranch("main", _ => _
                .WithLabel("beta")
                .WithVersioningMode(VersioningMode.Mainline)
                .WithIncrement(IncrementStrategy.Minor)
            ).Build();

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

        // expected 1.0.0 or 1.1.0-beta.0
        fixture.AssertFullSemver("1.0.0-beta.0", configuration);

        fixture.MakeACommit();

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

        fixture.ApplyTag("1.1.0");

        // expected 1.1.0 or 1.2.0-beta.0
        fixture.AssertFullSemver("1.1.0-beta.0", configuration);

        fixture.MakeACommit("testing +semver: fix");

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

        fixture.CreateBranch("feature/add_scripts");

        fixture.MakeACommit("Adding my scripts, +semver:patch");

        fixture.Checkout("main");

        fixture.MergeNoFF("feature/add_scripts");

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

[asbjornu]

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.

Thanks for sharing that information @wmclifford, it's very helpful to know how other tools deal with the same problems.

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.

We would keep Enabled for backwards compatibility and just write in the documentation that it's an alias for Coalesce. Over time we might deprecate Enabled with a warning and finally remove it in a major version.

[andreear-23]

To the seconde unit test: If you use bump messages then it's better to not use next-version at least for mainline mode (I think it is a bug in the implementation). In advance I'm not sure if the usage of pre-release label on a mainline branch makes sense. I thougth mainline alias trunkbased workflow not using tags at all?

Please try this:

Hi there, so I tried out the latest test and it works - that made me to realize I need to use the mainline mode and also to expect the patch version increase in my devel branch after I merge the feature branch, this was one thing I was doing wrong.

I did these changes on my current repo, also added a new tag since I wanted to have consistency that was missing due to my earlier mistakes, built the project on CI and the gitversion was exactly what I hoped and expected.
However, starting from the earlier point described above I tried to merge in another branch, a bugfix branch this time and the version does again not increase the way I would expect it.
So I have my devel branch with gitversion 1.1.1-dev.19, I have my bugfix branch with version 1.1.1-post.21 on which I do an empty commit with the message bump up version +semver:fix. I merge bugfix into devel and the gitversion I get is 1.1.1-dev.22.
Am I misunderstanding again the behaviour and did I do something wrong or what is happening here? My theory is that whenever I create a tag the gitversion works properly once and then the next version increase fails.

Here's the output of running gitversion between each step:

root@79a0b7234607:/workspace/my_project# gitversion  // on my bugfix branch before commiting with the +semver keyword
{                                                                                   
  "Major": 1,                                                                       
  "Minor": 1,                                                                       
  "Patch": 1,                                                                       
  "PreReleaseTag": "post.21",                                                       
  "PreReleaseTagWithDash": "-post.21",                                              
  "PreReleaseLabel": "post",                                                        
  "PreReleaseLabelWithDash": "-post",                                               
  "PreReleaseNumber": 21,                                                           
  "WeightedPreReleaseNumber": 30021,                                                
  "BuildMetaData": null,                                                            
  "BuildMetaDataPadded": "",                                                        
  "FullBuildMetaData": "Branch.bugfix-security-default-os.Sha.fe2771c4c557eadc989002b6204712c04fc968a0",
  "MajorMinorPatch": "1.1.1",                                                       
  "SemVer": "1.1.1-post.21",                                                        
  "LegacySemVer": "1.1.1-post21",                                                   
  "LegacySemVerPadded": "1.1.1-post0021",                                           
  "AssemblySemVer": "1.1.1.0",                                                      
  "AssemblySemFileVer": "1.1.1.0",                                                  
  "FullSemVer": "1.1.1-post.21",                                                    
  "InformationalVersion": "1.1.1-post.21+Branch.bugfix-security-default-os.Sha.fe2771c4c557eadc989002b6204712c04fc968a0",
  "BranchName": "bugfix/security_default_os",                                       
  "EscapedBranchName": "bugfix-security-default-os",                                
  "Sha": "fe2771c4c557eadc989002b6204712c04fc968a0",                                
  "ShortSha": "fe2771c",                                                            
  "NuGetVersionV2": "1.1.1-post0021",                                               
  "NuGetVersion": "1.1.1-post0021",                                                 
  "NuGetPreReleaseTagV2": "post0021",                                               
  "NuGetPreReleaseTag": "post0021",                                                 
  "VersionSourceSha": "f28debcc04dbcb94b477fb6f9c178fe78c2750c0",                   
  "CommitsSinceVersionSource": 21,                                                  
  "CommitsSinceVersionSourcePadded": "0021",                                        
  "UncommittedChanges": 14,                                                         
  "CommitDate": "2023-05-04"                                                        
}  

root@79a0b7234607:/workspace/my_project# gitversion // on my bugfix branch after commiting with the +semver keyword                              
{                                                                                   
  "Major": 1,                                                                       
  "Minor": 1,                                                                       
  "Patch": 1,                                                                       
  "PreReleaseTag": "post.22",
  "PreReleaseTagWithDash": "-post.22",
  "PreReleaseLabel": "post",
  "PreReleaseLabelWithDash": "-post",
  "PreReleaseNumber": 22,
  "WeightedPreReleaseNumber": 30022,
  "BuildMetaData": null,
  "BuildMetaDataPadded": "",
  "FullBuildMetaData": "Branch.bugfix-security-default-os.Sha.8d4dcf21b4c05cb018268f22d8328965a98e8d76",
  "MajorMinorPatch": "1.1.1",
  "SemVer": "1.1.1-post.22",
  "LegacySemVer": "1.1.1-post22",
  "LegacySemVerPadded": "1.1.1-post0022",
  "AssemblySemVer": "1.1.1.0",
  "AssemblySemFileVer": "1.1.1.0",
  "FullSemVer": "1.1.1-post.22",
  "InformationalVersion": "1.1.1-post.22+Branch.bugfix-security-default-os.Sha.8d4dcf21b4c05cb018268f22d8328965a98e8d76",
  "BranchName": "bugfix/security_default_os",
  "EscapedBranchName": "bugfix-security-default-os",
  "Sha": "8d4dcf21b4c05cb018268f22d8328965a98e8d76",
  "ShortSha": "8d4dcf2",
  "NuGetVersionV2": "1.1.1-post0022",
  "NuGetVersion": "1.1.1-post0022",
  "NuGetPreReleaseTagV2": "post0022",
  "NuGetPreReleaseTag": "post0022",
  "VersionSourceSha": "f28debcc04dbcb94b477fb6f9c178fe78c2750c0",
  "CommitsSinceVersionSource": 22,
  "CommitsSinceVersionSourcePadded": "0022",
  "UncommittedChanges": 14,
  "CommitDate": "2023-05-04"
}                                  

root@79a0b7234607:/workspace/my_project# gitversion // on my devel branch before merging in the bugfix branch
{                                         
  "Major": 1,                             
  "Minor": 1,                             
  "Patch": 1,                             
  "PreReleaseTag": "dev.19",
  "PreReleaseTagWithDash": "-dev.19",
  "PreReleaseLabel": "dev",
  "PreReleaseLabelWithDash": "-dev",
  "PreReleaseNumber": 19,
  "WeightedPreReleaseNumber": 19,
  "BuildMetaData": null,
  "BuildMetaDataPadded": "",
  "FullBuildMetaData": "Branch.devel.Sha.debd240b7add16601da8e3cfeaa7c623232b9075",
  "MajorMinorPatch": "1.1.1",
  "SemVer": "1.1.1-dev.19",
  "LegacySemVer": "1.1.1-dev19",
  "LegacySemVerPadded": "1.1.1-dev0019",
  "AssemblySemVer": "1.1.1.0",
  "AssemblySemFileVer": "1.1.1.0",
  "FullSemVer": "1.1.1-dev.19",
  "InformationalVersion": "1.1.1-dev.19+Branch.devel.Sha.debd240b7add16601da8e3cfeaa7c623232b9075",
  "BranchName": "devel",
  "EscapedBranchName": "devel",
  "Sha": "debd240b7add16601da8e3cfeaa7c623232b9075",
  "ShortSha": "debd240",
  "NuGetVersionV2": "1.1.1-dev0019",
  "NuGetVersion": "1.1.1-dev0019",
  "NuGetPreReleaseTagV2": "dev0019",
  "NuGetPreReleaseTag": "dev0019",
  "VersionSourceSha": "f28debcc04dbcb94b477fb6f9c178fe78c2750c0",
  "CommitsSinceVersionSource": 19,
  "CommitsSinceVersionSourcePadded": "0019",
  "UncommittedChanges": 14,
  "CommitDate": "2023-05-04"
}                                         

root@79a0b7234607:/workspace/my_project# gitversion  // on my devel branch after merging in the bugfix branch
{
  "Major": 1,
  "Minor": 1,
  "Patch": 1,
  "PreReleaseTag": "dev.22",
  "PreReleaseTagWithDash": "-dev.22",
  "PreReleaseLabel": "dev",
  "PreReleaseLabelWithDash": "-dev",
  "PreReleaseNumber": 22,
  "WeightedPreReleaseNumber": 22,
  "BuildMetaData": null,
  "BuildMetaDataPadded": "",
  "FullBuildMetaData": "Branch.devel.Sha.8d4dcf21b4c05cb018268f22d8328965a98e8d76",
  "MajorMinorPatch": "1.1.1",
  "SemVer": "1.1.1-dev.22",
  "LegacySemVer": "1.1.1-dev22",
  "LegacySemVerPadded": "1.1.1-dev0022",
  "AssemblySemVer": "1.1.1.0",
  "AssemblySemFileVer": "1.1.1.0",
  "FullSemVer": "1.1.1-dev.22",
  "InformationalVersion": "1.1.1-dev.22+Branch.devel.Sha.8d4dcf21b4c05cb018268f22d8328965a98e8d76",
  "BranchName": "devel",
  "EscapedBranchName": "devel",
  "Sha": "8d4dcf21b4c05cb018268f22d8328965a98e8d76",
  "ShortSha": "8d4dcf2",
  "NuGetVersionV2": "1.1.1-dev0022",
  "NuGetVersion": "1.1.1-dev0022",
  "NuGetPreReleaseTagV2": "dev0022",
  "NuGetPreReleaseTag": "dev0022",
  "VersionSourceSha": "f28debcc04dbcb94b477fb6f9c178fe78c2750c0",
  "CommitsSinceVersionSource": 22,
  "CommitsSinceVersionSourcePadded": "0022",
  "UncommittedChanges": 14,
  "CommitDate": "2023-05-04"
}

Also I attached the used gitversion config, both the GitVersion.yml and the output of running gitversion /showconfig. I added it as a file for the sake of not having a huge reply.
config.txt

Thanks for all your help!

[HHobeck]

To the seconde unit test: If you use bump messages then it's better to not use next-version at least for mainline mode (I think it is a bug in the implementation). In advance I'm not sure if the usage of pre-release label on a mainline branch makes sense. I thougth mainline alias trunkbased workflow not using tags at all?
Please try this:

Hi there, so I tried out the latest test and it works - that made me to realize I need to use the mainline mode and also to expect the patch version increase in my devel branch after I merge the feature branch, this was one thing I was doing wrong.

I did these changes on my current repo, also added a new tag since I wanted to have consistency that was missing due to my earlier mistakes, built the project on CI and the gitversion was exactly what I hoped and expected. However, starting from the earlier point described above I tried to merge in another branch, a bugfix branch this time and the version does again not increase the way I would expect it. So I have my devel branch with gitversion 1.1.1-dev.19, I have my bugfix branch with version 1.1.1-post.21 on which I do an empty commit with the message bump up version +semver:fix. I merge bugfix into devel and the gitversion I get is 1.1.1-dev.22. Am I misunderstanding again the behaviour and did I do something wrong or what is happening here? My theory is that whenever I create a tag the gitversion works properly once and then the next version increase fails.

Here's the output of running gitversion between each step:

root@79a0b7234607:/workspace/my_project# gitversion  // on my bugfix branch before commiting with the +semver keyword
{                                                                                   
  "Major": 1,                                                                       
  "Minor": 1,                                                                       
  "Patch": 1,                                                                       
  "PreReleaseTag": "post.21",                                                       
  "PreReleaseTagWithDash": "-post.21",                                              
  "PreReleaseLabel": "post",                                                        
  "PreReleaseLabelWithDash": "-post",                                               
  "PreReleaseNumber": 21,                                                           
  "WeightedPreReleaseNumber": 30021,                                                
  "BuildMetaData": null,                                                            
  "BuildMetaDataPadded": "",                                                        
  "FullBuildMetaData": "Branch.bugfix-security-default-os.Sha.fe2771c4c557eadc989002b6204712c04fc968a0",
  "MajorMinorPatch": "1.1.1",                                                       
  "SemVer": "1.1.1-post.21",                                                        
  "LegacySemVer": "1.1.1-post21",                                                   
  "LegacySemVerPadded": "1.1.1-post0021",                                           
  "AssemblySemVer": "1.1.1.0",                                                      
  "AssemblySemFileVer": "1.1.1.0",                                                  
  "FullSemVer": "1.1.1-post.21",                                                    
  "InformationalVersion": "1.1.1-post.21+Branch.bugfix-security-default-os.Sha.fe2771c4c557eadc989002b6204712c04fc968a0",
  "BranchName": "bugfix/security_default_os",                                       
  "EscapedBranchName": "bugfix-security-default-os",                                
  "Sha": "fe2771c4c557eadc989002b6204712c04fc968a0",                                
  "ShortSha": "fe2771c",                                                            
  "NuGetVersionV2": "1.1.1-post0021",                                               
  "NuGetVersion": "1.1.1-post0021",                                                 
  "NuGetPreReleaseTagV2": "post0021",                                               
  "NuGetPreReleaseTag": "post0021",                                                 
  "VersionSourceSha": "f28debcc04dbcb94b477fb6f9c178fe78c2750c0",                   
  "CommitsSinceVersionSource": 21,                                                  
  "CommitsSinceVersionSourcePadded": "0021",                                        
  "UncommittedChanges": 14,                                                         
  "CommitDate": "2023-05-04"                                                        
}  

root@79a0b7234607:/workspace/my_project# gitversion // on my bugfix branch after commiting with the +semver keyword                              
{                                                                                   
  "Major": 1,                                                                       
  "Minor": 1,                                                                       
  "Patch": 1,                                                                       
  "PreReleaseTag": "post.22",
  "PreReleaseTagWithDash": "-post.22",
  "PreReleaseLabel": "post",
  "PreReleaseLabelWithDash": "-post",
  "PreReleaseNumber": 22,
  "WeightedPreReleaseNumber": 30022,
  "BuildMetaData": null,
  "BuildMetaDataPadded": "",
  "FullBuildMetaData": "Branch.bugfix-security-default-os.Sha.8d4dcf21b4c05cb018268f22d8328965a98e8d76",
  "MajorMinorPatch": "1.1.1",
  "SemVer": "1.1.1-post.22",
  "LegacySemVer": "1.1.1-post22",
  "LegacySemVerPadded": "1.1.1-post0022",
  "AssemblySemVer": "1.1.1.0",
  "AssemblySemFileVer": "1.1.1.0",
  "FullSemVer": "1.1.1-post.22",
  "InformationalVersion": "1.1.1-post.22+Branch.bugfix-security-default-os.Sha.8d4dcf21b4c05cb018268f22d8328965a98e8d76",
  "BranchName": "bugfix/security_default_os",
  "EscapedBranchName": "bugfix-security-default-os",
  "Sha": "8d4dcf21b4c05cb018268f22d8328965a98e8d76",
  "ShortSha": "8d4dcf2",
  "NuGetVersionV2": "1.1.1-post0022",
  "NuGetVersion": "1.1.1-post0022",
  "NuGetPreReleaseTagV2": "post0022",
  "NuGetPreReleaseTag": "post0022",
  "VersionSourceSha": "f28debcc04dbcb94b477fb6f9c178fe78c2750c0",
  "CommitsSinceVersionSource": 22,
  "CommitsSinceVersionSourcePadded": "0022",
  "UncommittedChanges": 14,
  "CommitDate": "2023-05-04"
}                                  

root@79a0b7234607:/workspace/my_project# gitversion // on my devel branch before merging in the bugfix branch
{                                         
  "Major": 1,                             
  "Minor": 1,                             
  "Patch": 1,                             
  "PreReleaseTag": "dev.19",
  "PreReleaseTagWithDash": "-dev.19",
  "PreReleaseLabel": "dev",
  "PreReleaseLabelWithDash": "-dev",
  "PreReleaseNumber": 19,
  "WeightedPreReleaseNumber": 19,
  "BuildMetaData": null,
  "BuildMetaDataPadded": "",
  "FullBuildMetaData": "Branch.devel.Sha.debd240b7add16601da8e3cfeaa7c623232b9075",
  "MajorMinorPatch": "1.1.1",
  "SemVer": "1.1.1-dev.19",
  "LegacySemVer": "1.1.1-dev19",
  "LegacySemVerPadded": "1.1.1-dev0019",
  "AssemblySemVer": "1.1.1.0",
  "AssemblySemFileVer": "1.1.1.0",
  "FullSemVer": "1.1.1-dev.19",
  "InformationalVersion": "1.1.1-dev.19+Branch.devel.Sha.debd240b7add16601da8e3cfeaa7c623232b9075",
  "BranchName": "devel",
  "EscapedBranchName": "devel",
  "Sha": "debd240b7add16601da8e3cfeaa7c623232b9075",
  "ShortSha": "debd240",
  "NuGetVersionV2": "1.1.1-dev0019",
  "NuGetVersion": "1.1.1-dev0019",
  "NuGetPreReleaseTagV2": "dev0019",
  "NuGetPreReleaseTag": "dev0019",
  "VersionSourceSha": "f28debcc04dbcb94b477fb6f9c178fe78c2750c0",
  "CommitsSinceVersionSource": 19,
  "CommitsSinceVersionSourcePadded": "0019",
  "UncommittedChanges": 14,
  "CommitDate": "2023-05-04"
}                                         

root@79a0b7234607:/workspace/my_project# gitversion  // on my devel branch after merging in the bugfix branch
{
  "Major": 1,
  "Minor": 1,
  "Patch": 1,
  "PreReleaseTag": "dev.22",
  "PreReleaseTagWithDash": "-dev.22",
  "PreReleaseLabel": "dev",
  "PreReleaseLabelWithDash": "-dev",
  "PreReleaseNumber": 22,
  "WeightedPreReleaseNumber": 22,
  "BuildMetaData": null,
  "BuildMetaDataPadded": "",
  "FullBuildMetaData": "Branch.devel.Sha.8d4dcf21b4c05cb018268f22d8328965a98e8d76",
  "MajorMinorPatch": "1.1.1",
  "SemVer": "1.1.1-dev.22",
  "LegacySemVer": "1.1.1-dev22",
  "LegacySemVerPadded": "1.1.1-dev0022",
  "AssemblySemVer": "1.1.1.0",
  "AssemblySemFileVer": "1.1.1.0",
  "FullSemVer": "1.1.1-dev.22",
  "InformationalVersion": "1.1.1-dev.22+Branch.devel.Sha.8d4dcf21b4c05cb018268f22d8328965a98e8d76",
  "BranchName": "devel",
  "EscapedBranchName": "devel",
  "Sha": "8d4dcf21b4c05cb018268f22d8328965a98e8d76",
  "ShortSha": "8d4dcf2",
  "NuGetVersionV2": "1.1.1-dev0022",
  "NuGetVersion": "1.1.1-dev0022",
  "NuGetPreReleaseTagV2": "dev0022",
  "NuGetPreReleaseTag": "dev0022",
  "VersionSourceSha": "f28debcc04dbcb94b477fb6f9c178fe78c2750c0",
  "CommitsSinceVersionSource": 22,
  "CommitsSinceVersionSourcePadded": "0022",
  "UncommittedChanges": 14,
  "CommitDate": "2023-05-04"
}

Also I attached the used gitversion config, both the GitVersion.yml and the output of running gitversion /showconfig. I added it as a file for the sake of not having a huge reply. config.txt

Thanks for all your help!

Please write an integration test for your scenario with actual and exptected version annotation... Otherwise I cannot follow your thoughts.

[HHobeck]

I have my bugfix branch with version 1.1.1-post.21 on which I do an empty commit with the message bump up version +semver:fix

The bump message increment behaves different depending on whether you run it on branches with mainline or non-mainline mode. In this case I expect you are in a branch with ContinuousDelivery mode with increment Patch and complaining about that nothing happened when creating a message with semver+: patch right!?

The bump message feature like it is implemented in the actual version of git-version is there to bump the increment to a higher value for the calculation of the next version. If lets say the base version is 1.0.0 then the following matrix applies:

A commit without a bump message yields:

• on branches with increment none to 1.0.0
• on branches with increment patch to 1.0.1
• on branches with increment minor to 1.1.0
• on branches with increment major to 2.0.0

A commit with semver+: patch message yields

• on branches with increment none to 1.0.1
• on branches increment patch to 1.0.1
• on branches increment minor to 1.1.0
• on branches increment major to 2.0.0

A commit with semver+: minor message yields

• on branches with increment none to 1.1.0
• on branches with increment patch to 1.1.0
• on branches with increment minor to 1.1.0
• on branches with increment major to 2.0.0

A commit with semver+: major message yields

• on branches with increment none to 2.0.0
• on branches with increment patch to 2.0.0
• on branches with increment minor to 2.0.0
• on branches with increment major to 2.0.0

May I ask you: Why would you bump the version e.g. the patch version to 1.0.2 and skip the version 1.0.1 without releasing it?

[HHobeck]

What I'm trying to say is you need to think about the use case of using the bump message feature. The motivation is more dependent on what changes your commit includes from the development perspective. When you in the role of a developer don't care about what the target branch might be and think: "Oh it's not just a minor change it’s a huge change which should yield to a major version increment because I have updated the API with a breaking change." Hope that's understandable.

[andreear-23]

Please write an integration test for your scenario with actual and exptected version annotation... Otherwise I cannot follow your thoughts.

Hi, I tried to write a test to replicate the situation that I have and am expecting:

    [Test]
    public void JustATest()
    {
        var configuration = GitFlowConfigurationBuilder.New
            .WithSemanticVersionFormat(SemanticVersionFormat.Loose)
            .WithCommitMessageIncrementing(CommitMessageIncrementMode.Enabled)
            .WithBranch("main", _ => _
                .WithLabel("dev")
                .WithVersioningMode(VersioningMode.Mainline)
                .WithIncrement(IncrementStrategy.Patch)
            ).Build();

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

        fixture.AssertFullSemver("1.1.1-dev.0", configuration);

        fixture.CreateBranch("bugfix/security");

        fixture.MakeACommit("Adding my scripts");
        fixture.MakeACommit("bump up version +semver:patch");

        fixture.Checkout("main");

        fixture.MergeNoFF("bugfix/security");

      // fails with message that version was actually "1.1.3-dev.2" 
        fixture.AssertFullSemver("1.1.2-dev.2", configuration);
    }

Changing the .WithIncrement to IncrementStrategy.Minor (as I want it to be on the main branch) gives:

   Shouldly.ShouldAssertException : variables.FullSemVer                                                                                                                 
    should be                                                                                                                                                            
"1.1.2-dev.2"                                                                                                                                                            
    but was
"1.2.1-dev.2"
    difference

Furthermore changing the branch to be develop instead of main in order to reproduce my actual setup even closer, gives a completely different error instead:

    [Test]
    public void JustATest()
    {
        var configuration = GitFlowConfigurationBuilder.New
            .WithSemanticVersionFormat(SemanticVersionFormat.Loose)
            .WithCommitMessageIncrementing(CommitMessageIncrementMode.Enabled)
            .WithBranch("develop", _ => _
                .WithLabel("dev")
                .WithVersioningMode(VersioningMode.Mainline)
                .WithIncrement(IncrementStrategy.Minor)
            ).Build();

        using EmptyRepositoryFixture fixture = new("develop");
        fixture.MakeATaggedCommit("1.1.1");

        fixture.AssertFullSemver("1.1.1-dev.0", configuration);

        fixture.CreateBranch("bugfix/security");

        fixture.MakeACommit("Adding my scripts");
        fixture.MakeACommit("bump up version +semver:patch");

        fixture.Checkout("develop");

        fixture.MergeNoFF("bugfix/security");


        fixture.AssertFullSemver("1.1.2-dev.2", configuration);
    }

gives this error message

GitVersion.WarningException : No branches can be found matching the commit 46aa4d885f44e603a7f4b6e16ce2450599874f4b in the configured Mainline branches: main, support

which makes me think that somehow the Mainline mode doesn't support using a branch called develop as the main branch?

May I ask you: Why would you bump the version e.g. the patch version to 1.0.2 and skip the version 1.0.1 without releasing it?

In a way I am doing a release (maybe I misunderstand the term however) since everytime the devel branch of my repo gets updated with a PR the CI triggers a build that builds a pip wheel and uploads it to an artifactory. We're developing a small internal python library to which multiple people are contributing. One can only contribute to the devel branch via a PR - so now we have 4 open PRs with small changes to the library and after merging each PR our CI will trigger.
I am trying to use gitversion for automatically bumping up the version of the library instead of someone always having to manually edit the setup.py and increase from v1.1.0 to v1.1.1 - and if they forget to do it the CI will get a failed build.

What I'm trying to say is you need to think about the use case of using the bump message feature. The motivation is more dependent on what changes your commit includes from the development perspective. When you in the role of a developer don't care about what the target branch might be and think: "Oh it's not just a minor change it’s a huge change which should yield to a major version increment because I have updated the API with a breaking change." Hope that's understandable.

It's true that the development workflow influences a lot the way the versions get changed however I think each developer has his own way of working and while someone might add their changes in 4 different branches vs someone who adds it into 1 single one depends a lot on the context and the situation.

Thanks a lot for your help and patience though! :)

[HHobeck]

Okay I think you have a fundamental misunderstanding about the common used branching and merging strategies. This is in most cases the git hub flow or the git flow and in my opinion the trunk based workflow (of course there are maybe more out there but this is mainly supported by git version). I would recommend you to take a look to the following documentation: https://gitversion.net/docs/learn/branching-strategies/

[HHobeck]

In a way I am doing a release (maybe I misunderstand the term however) since everytime the devel branch of my repo gets updated with a PR the CI triggers a build that builds a pip wheel and uploads it to an artifactory. We're developing a small internal python library to which multiple people are contributing. One can only contribute to the devel branch via a PR - so now we have 4 open PRs with small changes to the library and after merging each PR our CI will trigger.
I am trying to use gitversion for automatically bumping up the version of the library instead of someone always having to manually edit the setup.py and increase from v1.1.0 to v1.1.1 - and if they forget to do it the CI will get a failed build.

GitVersion is a tool to generate the sematic version based on the current state of your git repository. Each version increment (independent of whether you change the major, minor or patch number) means you have a new version of a product with dedicated bugfixes and features. If you are planning a feature release e.g. 1.1.0 then you of course create sometimes release candidates for testing purpose or whatever. This release candidates normally are labeled with a pre-release name and/or number.

If you take the git flow workflow an think about the following scenario:

1. First commit on release/1.1.0 branch yields to 1.1.0-beta-1 (Release Candidate (RC) 1)
2. Second commit on release/1.1.0 branch yields to 1.1.0-beta-2 (RC 2)
3. and so on until you are going to approve the RC and say it's ready for production.
4. Then you are going to merge it to main and tag it with the version 1.1.0 (Release To Manufacturing (RTM))

then you see that pre-release number (aliase revision number) is used for that purpose.

[andreear-23]

Hi,
Is it possible that gitversion is using the entire history of the repo (of all the branches) to compute the version for a specific commit?
I just encountered a strange situation where for the same commit SHA, on the same branch, I get 2 different semver depending on whether I merged the branch into main or not.

For example, with the current state of my local repo I get the current semver output:

root@db4509ae6454:/workspace/myproject# gitversion                                                                                                                                                                            
{                                                                                                                                                                                                                                 
  "Major": 1,                                                                                                                                                                                                                     
  "Minor": 1,                                                                                                                                                                                                                     
  "Patch": 1,                                                                                                                                                                                                                     
  "PreReleaseTag": "post.22",                                                                                                                                                                                                     
  "PreReleaseTagWithDash": "-post.22",                                                                                                                                                                                            
  "PreReleaseLabel": "post",                                                                                                                                                                                                      
  "PreReleaseLabelWithDash": "-post",                                                                                                                                                                                             
  "PreReleaseNumber": 22,                                                                                                                                                                                                         
  "WeightedPreReleaseNumber": 30022,                                                                                                                                                                                              
  "BuildMetaData": null,                                                                                                                                                                                                          
  "BuildMetaDataPadded": "",                                                      // this is the SHA of the commit                                                                                                                                                
  "FullBuildMetaData": "Branch.bugfix-security-default-os.Sha.8d4dcf21b4c05cb018268f22d8328965a98e8d76",                                                                                                                          
  "MajorMinorPatch": "1.1.1",                                                                                                                                                                                                     
  "SemVer": "1.1.1-post.22",                                                                                                                                                                                                      
  "LegacySemVer": "1.1.1-post22",                                                                                                                                                                                                 
  "LegacySemVerPadded": "1.1.1-post0022",                                                                                                                                                                                         
  "AssemblySemVer": "1.1.1.0",                                                                                                                                                                                                    
  "AssemblySemFileVer": "1.1.1.0",                                                                                                                                                                                                
  "FullSemVer": "1.1.1-post.22",                                                                                                                                                                                                  
  "InformationalVersion": "1.1.1-post.22+Branch.bugfix-security-default-os.Sha.8d4dcf21b4c05cb018268f22d8328965a98e8d76",                                                                                                         
  "BranchName": "bugfix/security_default_os",                                                                                                                                                                                     
  "EscapedBranchName": "bugfix-security-default-os",                                                                                                                                                                              
  "Sha": "8d4dcf21b4c05cb018268f22d8328965a98e8d76",                                                                                                                                                                              
  "ShortSha": "8d4dcf2",                                                                                                                                                                                                          
  "NuGetVersionV2": "1.1.1-post0022",                                                                                                                                                                                             
  "NuGetVersion": "1.1.1-post0022",                                                                                                                                                                                               
  "NuGetPreReleaseTagV2": "post0022",                                                                                                                                                                                             
  "NuGetPreReleaseTag": "post0022",                                                                                                                                                                                               
  "VersionSourceSha": "f28debcc04dbcb94b477fb6f9c178fe78c2750c0",                                                                                                                                                                 
  "CommitsSinceVersionSource": 22,                                                                                                                                                                                                
  "CommitsSinceVersionSourcePadded": "0022",                                                                                                                                                                                      
  "UncommittedChanges": 14,                                                                                                                                                                                                       
  "CommitDate": "2023-05-04"                                                                                                                                                                                                      
}     

After merging a branch into main, going back to my bugfix branch and checking the version, this is the output:

root@db4509ae6454:/workspace/atd_common_py# gitversion
{
  "Major": 1,
  "Minor": 1,
  "Patch": 4,
  "PreReleaseTag": "post.0",
  "PreReleaseTagWithDash": "-post.0",
  "PreReleaseLabel": "post",
  "PreReleaseLabelWithDash": "-post",
  "PreReleaseNumber": 0,
  "WeightedPreReleaseNumber": 30000,
  "BuildMetaData": null,
  "BuildMetaDataPadded": "",                                                            // same commit SHA
  "FullBuildMetaData": "Branch.bugfix-security-default-os.Sha.8d4dcf21b4c05cb018268f22d8328965a98e8d76",
  "MajorMinorPatch": "1.1.4",
  "SemVer": "1.1.4-post.0",
  "LegacySemVer": "1.1.4-post0",
  "LegacySemVerPadded": "1.1.4-post0000",
  "AssemblySemVer": "1.1.4.0",
  "AssemblySemFileVer": "1.1.4.0",
  "FullSemVer": "1.1.4-post.0",
  "InformationalVersion": "1.1.4-post.0+Branch.bugfix-security-default-os.Sha.8d4dcf21b4c05cb018268f22d8328965a98e8d76",
  "BranchName": "bugfix/security_default_os",
  "EscapedBranchName": "bugfix-security-default-os",
  "Sha": "8d4dcf21b4c05cb018268f22d8328965a98e8d76",
  "ShortSha": "8d4dcf2",
  "NuGetVersionV2": "1.1.4-post0000",
  "NuGetVersion": "1.1.4-post0000",
  "NuGetPreReleaseTagV2": "post0000",
  "NuGetPreReleaseTag": "post0000",
  "VersionSourceSha": "8d4dcf21b4c05cb018268f22d8328965a98e8d76",
  "CommitsSinceVersionSource": 0,
  "CommitsSinceVersionSourcePadded": "0000",
  "UncommittedChanges": 14,
  "CommitDate": "2023-05-04"
}

It's the same SHA, same commit, same branch in both outputs. If gitversion truly uses the git history of all the branches in the repo then yes, that changes things a bit.

Thank you!

[HHobeck]

Is it possible that gitversion is using the entire history of the repo (of all the branches) to compute the version for a specific commit?

No it's highly dependent on which branch you are.

[HHobeck]

May I ask you is this discussion related to the initial issue you have posted or are you trying to implement your custom workflow and want just help? I'm asking because for that we have a dedicated question issue item you should use instead. Thank you!

[andreear-23]

Hi @HHobeck
I think the discussion degenerated towards me wanting to implement my custom workflow, although initially I opened it thinking there was a bug in gitversion with incrementing the patch version.
I will close this issue then and open a dedicated question issue. Thank you for all of your help!!