Increment 'Minor' number when merging feature branch in master in Mainline mode

[mabead]

I have a GitVersion.yml that contains the following

mode: Mainline
branches:
  feature:
    mode: ContinuousDeployment
    increment: Minor

So my intent is:

• feature branch should always increment 'minor' number.
• when feature branch is merged in master, it should bump the minor version of the master branch.

Note that if I don't set the mode to ContinousDeployment for my feature branches, then GitVersion does not increment the Minor version. It always increment the patch number. I don't understand why but that's not the point...

Then, look at the following operations:

PS C:\git\GitVersion.MainlineMode> git tag v1.3.0
PS C:\git\GitVersion.MainlineMode> (.\GitVersion\GitVersion.exe | Out-String -Stream | convertfrom-json).FullSemVer
1.3.0
PS C:\git\GitVersion.MainlineMode> git checkout -b features/some-feature
Switched to a new branch 'features/some-feature'
PS C:\git\GitVersion.MainlineMode> (.\GitVersion\GitVersion.exe | Out-String -Stream | convertfrom-json).FullSemVer
1.3.0
PS C:\git\GitVersion.MainlineMode> git commit --allow-empty -m 'commit 1'
[features/some-feature 01c04fa] commit 1
PS C:\git\GitVersion.MainlineMode> git commit --allow-empty -m 'commit 2'
[features/some-feature 003158c] commit 2
PS C:\git\GitVersion.MainlineMode> (.\GitVersion\GitVersion.exe | Out-String -Stream | convertfrom-json).FullSemVer
1.4.0-some-feature.2
PS C:\git\GitVersion.MainlineMode> git checkout master
Switched to branch 'master'
Your branch is based on 'origin/master', but the upstream is gone.
  (use "git branch --unset-upstream" to fixup)
PS C:\git\GitVersion.MainlineMode> (.\GitVersion\GitVersion.exe | Out-String -Stream | convertfrom-json).FullSemVer
1.3.0
PS C:\git\GitVersion.MainlineMode> git merge --no-ff features/some-feature
Already up-to-date!
Merge made by the 'recursive' strategy.
PS C:\git\GitVersion.MainlineMode> (.\GitVersion\GitVersion.exe | Out-String -Stream | convertfrom-json).FullSemVer
1.3.1

To summarize:

• I start from a repo that has the v1.3.0 tag
• I create a feature branch where I do two commits
• This branch tells me that it wants to be numbered 1.4.0 since GitVersion says that the full semver is 1.4.0-some-feature.2.
• Then, I merge this branch in master. At the point, GitVersion tells me that the version of the master branch is 1.3.1.

What am I doing wrong? What do I have to do for master to jump to 1.4.0 as requested by the feature branch that just got merged?

[mabead]

I would like to clarify what I want to achieve with GitVersion.

We are working in GitHubFlow mode. We have a master branch that we push to production everytime that a pull request is accepted in the master branch. We don't accept direct push in the master branch. Everything has to go through a pull request.

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.

We therefore don't want to use +semver:minor and +semver:patch commit messages to manage how the master branch number is incremented. 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.

This is a little similar to GitFlow where the name of the branch influences how the number of the master branch is incremented. For example, a branch starting with hotfixes/ will increment the patch number when merged in master where as a branch starting with releases/ will increment the minor number when merged in master. (I know it doesn't really increment the numbers... it picks the number from the branch names)

So, am I off track and GitVersion does not handle this desired behavior? If it is possible, how can it be done?

[asbjornu]

Which version of GitVersion are you using?

[mabead]

It was done yesterday with the latest version available on nuget.org. Since the version was updated yesterday on nuget.org, it was either 4.0.0-beta0012 or 4.0.0-beta0011. I don't have access to the machine where I did these tests currently. But i am sure it was beta11 or beta12. Do you think that beta 12 makes a difference?

[asbjornu]

It's worth a shot! 😄

[mabead]

I confirm that I was using GitVersion 4.0.0-beta.12+1315.Branch.master.Sha.9c70946f68973b3b31b2861913c247fbe6c3f0ec.

[asbjornu]

Oh, bummer. How do you feel like submitting a pull request with a failing test? Just have a look at the existing RepositoryFixture tests, they are pretty straight forward.

[mabead]

Note that you can see the problem in the following repository: https://github.com/mabead/GitVersion.MainlineMode.

I could for sure submit a failing test. But before doing so, can you confirm that it is a bug in GitVersion and not that I am simply doing it wrong?

[mabead]

Test has been added here: #1223

Good job for the tests by the way. They are very easy to read and augment.

[asbjornu]

@mabead: Thanks for the test. I'm not sure whether this is a bug yet, but a failing test is the absolute best way to inspect it and fix it if it is. 😃 👍

[mabead]

@JakeGinnivan Thanks for the fix! Do you know when a new NuGet package will be made available?

[mabead]

@asbjornu Do you plan to include this in a new NuGet package in the near future?