The same version generated twice

[dpurge]

I have stumbled on smth that looks like a bug to me .

Given this configuration (abbreviated from my unit tests for gitversion.yml):

next-version: 5.0
branches:
  master:
    regex: master
    tag: beta
    increment: Patch
    mode: ContinuousDeployment

I am getting this in my unit test log:

0001 Initial commit - expect beta.0
     git init .
     commit = True
          SemVer:               5.0.0-beta.0
          FullSemVer:           5.0.0-beta.0
          AssemblySemVer:       5.0.0.0
          AssemblySemFileVer:   5.0.0.0
          InformationalVersion: 5.0.0-beta.0+Branch.master.Sha.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

0002 No committed changes - expect beta.0
     commit = False
          SemVer:               5.0.0-beta.0
          FullSemVer:           5.0.0-beta.0
          AssemblySemVer:       5.0.0.0
          AssemblySemFileVer:   5.0.0.0
          InformationalVersion: 5.0.0-beta.0+Branch.master.Sha.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

0003 Commit changes - expect beta.1
     commit = True
          SemVer:               5.0.0-beta.1
          FullSemVer:           5.0.0-beta.1
          AssemblySemVer:       5.0.0.0
          AssemblySemFileVer:   5.0.0.0
          InformationalVersion: 5.0.0-beta.1+Branch.master.Sha.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

0004 Another commit - expect beta.2
     commit = True
          SemVer:               5.0.0-beta.2
          FullSemVer:           5.0.0-beta.2
          AssemblySemVer:       5.0.0.0
          AssemblySemFileVer:   5.0.0.0
          InformationalVersion: 5.0.0-beta.2+Branch.master.Sha.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

0005 Create tag for the release candidate 1, no changes committed after the tag
     git tag v5.0.0-rc.1
     commit = False
          SemVer:               5.0.0-rc.1
          FullSemVer:           5.0.0-rc.1
          AssemblySemVer:       5.0.0.0
          AssemblySemFileVer:   5.0.0.0
          InformationalVersion: 5.0.0-rc.1+Branch.master.Sha.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

0006 Simple commit - expect 5.0.1-beta.1
     commit = True
          SemVer:               5.0.0-beta.1
          FullSemVer:           5.0.0-beta.1
          AssemblySemVer:       5.0.0.0
          AssemblySemFileVer:   5.0.0.0
          InformationalVersion: 5.0.0-beta.1+Branch.master.Sha.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Note that in step 0003 and 0006 gitversion has returned the same semantic version: 5.0.0-beta.1
And then it continues the count, duplicating beta.2 and so on.

I see two problems with the observed behaviour:

• Gitversion generated non-unique version numbers which violates a pronciple of unique identification
• Gitversion generated a lower version after the higher one, which breaks correct sorting order (5.0.0-rc.1 is higher than 5.0.0-beta.1)

There is also an inconsistency: in step 0001 it started to count beta from 0 (which surprised me), but after the RC in step 0006 it started to count beta from 1.

In addition (I do not show this in the log to keep things simpler) after +semver:fix even though the patch number was increased, the beta suffix did not restart the count, which IMHO is not the right behaviour.

I am testing against version:
4.0.0-beta.12+1315.Branch.master.Sha.9c70946f68973b3b31b2861913c247fbe6c3f0ec

I would expect GitVersion to figure out that it needs to increase the version as every 5.0.0-beta would be lower than 5.0.0-rc.1, so given my configuration it should bump the patch number and re-start the beta count. Using this logic, the expected version would be: 5.0.1-beta.1

Any tips on how to get the configuration right will be appreciated, as I need to come up with working configuration for a team adopting this tool. I have only started to learn about gitversion; maybe I am not using it correctly?

[asbjornu]

Have you tried with mode: Mainline? Since all commits seems to be on master, that might be a more fitting mode for your use of GitVersion.

[dpurge]

Sorry, it's 2019, the bug was reported in 2017. I no longer remember the details, but GitVersion was not working reliably enough for us and in the end we have written our own task to calculate version numbers according to our own needs and strategy and it's working since then in most of our projects. I think it would be good to drop the need to maintain our own solution, but it's probably too late now.
One day I will come back to try GitVersion again (it is a cool project), but at the moment - we don't use it.

[asbjornu]

I'm sorry to hear that, @dpurge and I apologize for the absence. Whenever you feel like taking a look at GitVersion again, I hope it's reached a more stable state and suits your needs well. I'll close this and welcome you back whenever the opportunity presents itself. Godspeed!