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

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

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 25 (12 by maintainers)

Commits related to this issue

Remove next-version GitVersion bug, https://github.com/GitTools/GitVersion/issues/2441 — committed to ni/csharp-styleguide by Everest2020 4 years ago
Remove next-version because it is not supported in mainline mode https://github.com/GitTools/GitVersion/issues/2441 — committed to bradtglass/HarvestForecast.Client by bradtglass 2 years ago

Most upvoted comments

@b10-dslappendel, why is adding base-version: <base-version> to GitVersion.yml (a feature that does not exist) more reasonable than doing git tag <base-version> $(git rev-list --max-parents=0 HEAD)? Both options involve the same number of operations, with git tag doing it in a canonical, best-practice manner native to Git, while relying on base-version or next-version inside GitVersion.yml is doing it in a proprietary way with the former based on a non-existing feature and the latter based on a bug that is now fixed.

asbjornu on Feb 25, 2021

@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: []

clawrenceks on Nov 3, 2020

Sure, I will try to set up something 😃

techgeek03 on Oct 30, 2020