6.0.0.beta6 has other behavior than 6.0.0.beta5 for pull request

[edwardvandevorst-philips]

We are working with 6.0.0-beta.5 and while upgrading to 6.0.0-beta.6 we see different behavior, for example pull requests don't get a suffix anymore. I am not sure if this is due to our configuration.

First see the log below on a PR:

Found multiple base versions which will produce the same SemVer (1.2.0-PullRequest242.1), taking oldest source for commit counting (Git tag 'v1.1.0')

So here it looks like the version is calculated correctly (1.2.0-PullRequest242.1) but the output is github actions is 1.2.0 as you see below.

INFO [03/11/24 16:44:49:74] -------------------------------------------------------
INFO [03/11/24 16:44:49:74] Found multiple base versions which will produce the same SemVer (1.2.0-PullRequest242.1), taking oldest source for commit counting (Git tag 'v1.1.0')
INFO [03/11/24 16:44:49:74] Base version used: Git tag 'v1.1.0': 1.1.0 with commit source '410217965547154b8d8008d4707c0fb7349ca61b'
INFO [03/11/24 16:44:49:74] -------------------------------------------------------
INFO [03/11/24 16:44:49:74] -< Begin: Using continuous deployment workflow to calculate the incremented version. >-
  INFO [03/11/24 16:44:49:75] 372 commits found between '4102179' - Merge pull request #90 from philips-internal/chore/AB#628947-add-pack-step-intbuild-bat and '8a2ca3e' - Merge 3ab8007bccc3a1fc70a97903a5449e5f4c9c62fc into 8113d2c9c3b071d6a193073d098e0edc84f02843
INFO [03/11/24 16:44:49:75] -< End: Using continuous deployment workflow to calculate the incremented version. (Took: 6.83ms) >-
INFO [03/11/24 16:44:49:77] -< Begin: Write version variables to cache file /opt/actions-runner/_work/igtd-fmlibrary/igtd-fmlibrary/.git/gitversion_cache/D93DCD9DCFD09BE79D94A0A3884DD848CD1B1572 >-
INFO [03/11/24 16:44:49:80] -< End: Write version variables to cache file /opt/actions-runner/_work/igtd-fmlibrary/igtd-fmlibrary/.git/gitversion_cache/D93DCD9DCFD09BE79D94A0A3884DD848CD1B1572 (Took: 26.93ms) >-
Executing GenerateSetVersionMessage for 'GitHubActions'.

Executing GenerateBuildLogOutput for 'GitHubActions'.
Writing version variables to $GITHUB_ENV file for 'GitHubActions'.
{
  "AssemblySemFileVer": "1.2.0.0",
  "AssemblySemVer": "1.2.0.0",
  "BranchName": "pull/242/merge",
  "BuildMetaData": null,
  "CommitDate": "2024-03-11",
  "CommitsSinceVersionSource": 372,
  "EscapedBranchName": "pull-242-merge",
  "FullBuildMetaData": "Branch.pull-242-merge.Sha.8a2ca3e86ba1a48c7dfa18aa7a944c784bb6ae07",
  "FullSemVer": "1.2.0",
  "InformationalVersion": "1.2.0+Branch.pull-242-merge.Sha.8a2ca3e86ba1a48c7dfa18aa7a944c784bb6ae07",
  "Major": 1,
  "MajorMinorPatch": "1.2.0",
  "Minor": 2,
  "Patch": 0,
  "PreReleaseLabel": "",
  "PreReleaseLabelWithDash": "",
  "PreReleaseNumber": null,
  "PreReleaseTag": "",
  "PreReleaseTagWithDash": "",
  "SemVer": "1.2.0",
  "Sha": "8a2ca3e86ba1a48c7dfa18aa7a944c784bb6ae07",
  "ShortSha": "8a2ca3e",
  "UncommittedChanges": 2,
  "VersionSourceSha": "410217965547154b8d8008d4707c0fb7349ca61b",
  "WeightedPreReleaseNumber": 60000
}

This worked fine with 6.0.0-beta.5. Our configuration is:

assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatch
assembly-informational-format: "{InformationalVersion}"
increment: Inherit
ignore:
  sha: []
merge-message-formats: {}
branches:
  develop:
    mode: ContinuousDeployment
  main:
    mode: ContinuousDeployment
    label: null
  release:
    mode: ContinuousDeployment
    commit-message-incrementing: Disabled
  feature:
    mode: ContinuousDeployment
  pull-request:
    mode: ContinuousDeployment
  hotfix:
    mode: ContinuousDeployment
    commit-message-incrementing: Disabled
  support:
    mode: ContinuousDeployment
    label: null
major-version-bump-message: |
  ^(?<type>build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test|¯\\_\(ツ\)_\/¯)(?<scope>\(AB#([0-9]{6})\))(?<breaking>!)(?<subject>:\s.*)?
minor-version-bump-message: |
  ^(?<type>feat)(?<scope>\(AB#([0-9]{6})\))(?<subject>:\s.*)?
patch-version-bump-message: |
  ^(?<type>build|chore|ci|docs|fix|perf|refactor|revert|style|test|¯\\_\(ツ\)_\/¯)(?<scope>\(AB#([0-9]{6})\))(?<subject>:\s.*)?
commit-message-incrementing: Enabled
label: null

[HHobeck]

The behavior of ContinuesDeployment has changed and got in the version 6.0.0-beta.6 a new meaning. The breaking change documentation says:

The versioning mode has been renamed to deployment mode and consists of following values:

ManualDeployment (previously ContinuousDelivery)
ContinuousDelivery (previously ContinuousDeployment)
ContinuousDeployment (new)

See also #3492 (reply in thread):

Actually we are doing a refactoring on the versioning mode and redefined the meaning. At this moment (in the 6.0.0-beta.4 version of gitversion) we are not finished with the transformation and that is the reason why only the 5.x definition is documented (please take a look here). For this discussion I want to focus on the target design which is agreed here.

• ManualDeployment, (previously ContinuousDelivery)
• ContinuousDelivery, (previously ContinuousDeployment)
• ContinuousDeployment (New)
• Mainline (will be removed)

At the end I want to make clear it doesn't matter for the algorithm what mode you are using. It is just a representation of the calculated result which has at least the following parts {Major}, {Minor}, {Patch}, {CommitSinceLastTag}, {PreReleaseNumber} and {PreReleaseLabel}. If you take for instance a next version increment of {Major} = 1, {Minor} = 2, {Patch} = 3, {PreReleaseNumber} = 4, {PreReleaseLabel} = beta and {CommitSinceLastTag} = 5 then you get:

• for mode ManualDeployment 1.2.3-beta.4+5
• for mode ContinuesDelivery 1.2.3-beta.8 ({PreReleaseNumber} +{CommitSinceLastTag} -1) and
• for mode ContinuesDeployment 1.2.3 (the other parts will be not used for the semantic version)