[Bug] GitVersion no longer calculates version correctly for mainline mode

[techgeek03]

Describe the bug
Since version 5.5 when using Mainline mode GitVersion is not calculating the version at all and it gives ether the value in next-version or the version from the last tag.

Expected Behavior

To have correct version

Actual Behavior

Version is stacked at next-version or the version from the last tag

Steps to Reproduce

Here is a simple GitVersion.yaml file I have been using

mode: Mainline
next-version: 1.0.0
branches:
  feature:
    tag: beta.{BranchName}
ignore:
  sha: []
merge-message-formats: {}

After many commits in master branch this is the output of GitVersion

INFO [10/29/20 23:06:38:48] Dumping commit graph:
INFO [10/29/20 23:06:38:64] *   3cdb26c 23 minutes ago  (HEAD -> master)
|\
| * 41f9c14 24 minutes ago  (feature/y2)
|/
*   9367673 73 minutes ago
|\
| * eb5c77a 76 minutes ago  (feature/test)
|/
* f957b18 78 minutes ago  (tag: 1.1.0)
* 318e307 79 minutes ago

INFO [10/29/20 23:06:38:98] Using latest commit on specified branch
INFO [10/29/20 23:06:39:02] Running against branch: master (3cdb26cf21767b34a3ecc65662fa00717857100a)
INFO [10/29/20 23:06:39:02] Begin: Calculating base versions
  INFO [10/29/20 23:06:39:07] NextVersion in GitVersion configuration file: 1.0.0 with commit count source External Source
  INFO [10/29/20 23:06:39:16] Git tag '1.1.0': 1.1.0 with commit count source f957b18b8557ba7d40a4e7a1a72f160c250e386f
  INFO [10/29/20 23:06:39:18] Found multiple base versions which will produce the same SemVer (1.1.1), taking oldest source for commit counting (Git tag '1.1.0')
  INFO [10/29/20 23:06:39:18] Base version used: Git tag '1.1.0': 1.1.0 with commit count source f957b18b8557ba7d40a4e7a1a72f160c250e386f
  INFO [10/29/20 23:06:39:18] End: Calculating base versions (Took: 158.30ms)
  INFO [10/29/20 23:06:39:18] Begin: Using mainline development mode to calculate current version
    INFO [10/29/20 23:06:39:20] Found possible mainline branches: master
    INFO [10/29/20 23:06:39:20] Mainline for current branch is master
    INFO [10/29/20 23:06:39:20] 4 commits found between f957b18b8557ba7d40a4e7a1a72f160c250e386f and 3cdb26cf21767b34a3ecc65662fa00717857100a
  INFO [10/29/20 23:06:39:21] End: Using mainline development mode to calculate current version (Took: 23.36ms)
{
  "Major":1,
  "Minor":1,
  "Patch":0,
  "PreReleaseTag":4,
  "PreReleaseTagWithDash":"",
  "PreReleaseLabel":"",
  "PreReleaseNumber":"",
  "WeightedPreReleaseNumber":60000,
  "BuildMetaData":"",
  "BuildMetaDataPadded":"",
  "FullBuildMetaData":"Branch.master.Sha.3cdb26cf21767b34a3ecc65662fa00717857100a",
  "MajorMinorPatch":"1.1.0",
  "SemVer":"1.1.0",
  "LegacySemVer":"1.1.0",
  "LegacySemVerPadded":"1.1.0",
  "AssemblySemVer":"1.1.0.0",
  "AssemblySemFileVer":"1.1.0.0",
  "FullSemVer":"1.1.0",
  "InformationalVersion":"1.1.0+Branch.master.Sha.3cdb26cf21767b34a3ecc65662fa00717857100a",
  "BranchName":"master",
  "EscapedBranchName":"master",
  "Sha":"3cdb26cf21767b34a3ecc65662fa00717857100a",
  "ShortSha":"3cdb26c",
  "NuGetVersionV2":"1.1.0",
  "NuGetVersion":"1.1.0",
  "NuGetPreReleaseTagV2":"",
  "NuGetPreReleaseTag":"",
  "VersionSourceSha":"f957b18b8557ba7d40a4e7a1a72f160c250e386f",
  "CommitsSinceVersionSource":4,
  "CommitsSinceVersionSourcePadded":"0004",
  "UncommittedChanges":1,
  "CommitDate":"2020-10-29"
}
  INFO [10/29/20 23:06:39:26] Done writing

I tried using main as default branch as well but it had the same problem.

Context

We are using GitVersion in all our Azure DevOps pipelines and we have configured the pipeline task to use the latest version of GitVersion, so currently all our pipelines are reporting wrong versions.

Your Environment

• Version Used: 5.5
• Operating System and version (Windows 10, Ubuntu 18.04): Windows, OS X, Ubuntu 18.04

[asbjornu]

Thanks for the bug report. Are you able to submit a failing test in a pull request that reproduces this behaviour?

[techgeek03]

Sure, I will try to set up something :)

[techgeek03]

While setting up the test's to verify the bug I actually found the actual cause of this bug. It is the use of next-version. It looks like, when using next-version, the version is wrongly calculated.
However this was not the case in the previous version 5.3.7.
Navigating in the NextVersionCalculatorTests there is actually a test MergeIntoMainline that confirm the behaviour I'm explaining. And it looks like is introduced with #2356 that relates to #2335

So, my question now is this the actual behaviour? And if yes then maybe the documentation needs to be more explicit and explain better.

[asbjornu]

If you remove next-version, do you get the expected version number? I think #2356 was correct in introducing support for next-version, but if our documentation needs adjustment to reflect this fact, we would highly appreciate a PR that does so.

[techgeek03]

If you remove next-version, do you get the expected version number?
Yes, when next-version is not in the config file then the version is calculated correctly.

I can update the documentation but I first want to confirm the behaviour of next-version in context of Mainline mode.

At present, to me, it looks like next-version should only be used when you want the code coming from a branch into the main branch to have the value of next-version but you don't want to use the commit message to do that. However, and this is very importnat, the next commit coming in the main branch must remove next-version from config, otherwise it will again get the same next-version value. Am I correct? :)

If that is the case, I don't see much value in next-version in Mainline mode since it could lead to potential confusion. I would then rather just use the commit message. :)

[hallgeirl]

I can confirm this issue as well - this is a clear change in behavior from 5.3.x and earlier. We had to continue using the older versions since we use next-version.

Was it a conscious choice, or is it a bug? :-)

[asbjornu]

I was of the impression that until 5.5, next-version wasn't really supported with mode: Mainline at all and thus don't understand how the addition could break anything. I'm sorry for not being more knowledgeable about this, but I don't use either next-version, Mainline or commit message counting myself, so please bear with me.

@techgeek03, how were you using next-version in combination with mode: Mainline before 5.5?

At present, to me, it looks like next-version should only be used when you want the code coming from a branch into the main branch to have the value of next-version but you don't want to use the commit message to do that. However, and this is very importnat, the next commit coming in the main branch must remove next-version from config, otherwise it will again get the same next-version value. Am I correct? :)

Yes, this sounds like how next-version works regardless of mode.

If that is the case, I don't see much value in next-version in Mainline mode since it could lead to potential confusion. I would then rather just use the commit message. :)

Then don't use next-version? 🤷‍♂️

[clawrenceks]

There is a definite change in behaviour with regards to main mode here. Currently affecting all of my (over 100) pipelines. For now, the only choice for me is a downgrade back to version 5.3.7

[asbjornu]

Can you please explain how you used next-version in combination with mode: Mainline before 5.5, @clawrenceks?

[clawrenceks]

@asbjornu Sure - for us the next-version property serves a single purpose, we use it as part of initializing a repo into our GitVersion process. When we on board a new repo, the first version used by GitVersion will come from the next-version property.

From then on in, the next-version property has been ignored in our experience. At the end of our build pipeline we tag the commit using the version calculated by GitVersion, this then becomes the base version detected the next time the build is run. We squash all commits into master from PRs and allow the semver to be incremented by merge message only. When there is no specific merge message, we expect patch to be incremented, otherwise we use +semver: minor or +semver: major to bump a major or minor version on merge.

Since the change to 5.5, I am now seeing that when committing with no merge message, the version was not actually incremented at all - the version remained as per the last tag in the repo.

Our very simple config, which we have been using for a long time, is shown below.

mode: Mainline
commit-message-incrementing: MergeMessageOnly
next-version: 0.1.0
branches:
  feature:
    regex: feature(s)?[/-]
    mode: ContinuousDeployment
    tag: useBranchName
    increment: None
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
  pull-request:
    regex: (pull|pull\-requests|pr)[/-]
    mode: ContinuousDeployment
    tag: PullRequest
    increment: None
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    track-merge-target: false
  hotfix:
    regex: (hotfix(es)?|config)[/-]
    mode: ContinuousDeployment
    tag: useBranchName
    increment: None
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
ignore:
  sha: []

[asbjornu]

Thanks, @clawrenceks. From my understanding, the old behaviour seems like an oversight in the initial implementation of Mainline, then. next-version is not the same as initial-base-version (which doesn't exist). next-version and git tag are interchangeable and semantically means almost the same for GitVersion. That should apply regardless of which mode you use.

For everyone having problems with next-version in combination with mode: Mainline I would suggest to just remove next-version from GitVersion.yml and potentially add a tag indicating the same version at an old commit just to get the base version for computation correct.

[techgeek03]

@asbjornu In our case we used next-version only as a starting point for new repos to get a default base version and be aligned across the team. Yes we decided to remove next-version but having 50+ repo's makes this issue annoying :)

Intentionally or unintentionally it is a clear change of behaviour and in my view this constitutes as a breaking change, but since there is a workaround it is fine :)