Trying to replicate the example in the Mainline Development documentation and versioning is not incrementing as expected; Am I missing something here?

[davidandersen]

I thought I found some issues with GitVersion when using on my local and within GitHub actions on another project, but I took a step back and thought that I would attempt to replicate the example of what Mainline Development looks like from the documentation.

I was able to match to the documented versions up through 1.1.0+4, but when I created the branch feature/foo3, made a commit, and merged with main using +semver: minor in the merge message, the version did not increment to 1.2.0+6. Instead, it stayed as 1.1.0.

I proceeded to repeat the process, but using +semver: minor in the commit message, then merging, and the version still was not incremented to 1.2.0.

Does Mainline require me to tag main in order for versions to be incremented using +semver: [ type ]? I was under the impression that GitVersion will increment regardless of whether or not there is an explicit tag (but I am aware of the best practice to tag for performance reasons).

Click here for a link to the repo that I created that outlines the steps that I took to generate the versions.

If you go to the Actions tab, you will be able to see the history of the builds. Click here to be taken to the merge for feature/foo3.

In the build script there is a section where version is printed to the screen with a name of Run echo 1.1.0.

The configuration file being used can be found here.

Here is a screen shot of the version in the diagram from the documentation that illustrates where I'm failing to produce the correct version.

Any feedback would be greatly appreciated! Thanks!

[asbjornu]

It seems like you've configured all of your branches to use mode: ContinuousDelivery. To understand how Mainline works in GitVersion, I would recommend that you reduce your GitVersion.yml file to nothing but:

mode: Mainline

You may also consider fast-forward merging squashed commits of your feature branches into main instead of adding merge-commits. That is closer to how GitHub Flow (which is a type of Mainline flow) works.