How to correctly migrate from V5 Mainline mode to V6 Mainline versioning without changes in behaviour?

[hotchkj]

I have hundreds of repos configured for 5.12 with a config that is as follows:

mode: Mainline
assembly-versioning-scheme: MajorMinor
branches: {}
ignore:
  sha: []
merge-message-formats: {}

Lets' say I have a master branch with a commit tagged with v10.0.0 and eight more untagged commits after it, each of which had +semver: none in the commit message and correspondingly the build versioning skipped these as still producing v10.0.0 with no change in tag. GitVersion is being run at HEAD of master.

GitVersion 5.12.0 gives me 10.0.0 with a pre-release tag of 8 which gets skipped when forming FullSemVer:

JSON

{
  "Major": 10,
  "Minor": 0,
  "Patch": 0,
  "PreReleaseTag": "8",
  "PreReleaseTagWithDash": "",
  "PreReleaseLabel": "",
  "PreReleaseLabelWithDash": "",
  "PreReleaseNumber": null,
  "WeightedPreReleaseNumber": 60000,
  "BuildMetaData": null,
  "BuildMetaDataPadded": "",
  "FullBuildMetaData": "Branch.master.Sha.8947dafe06011c812599eb2b273830d916d367cf",
  "MajorMinorPatch": "10.0.0",
  "SemVer": "10.0.0",
  "LegacySemVer": "10.0.0",
  "LegacySemVerPadded": "10.0.0",
  "AssemblySemVer": "10.0.0.0",
  "AssemblySemFileVer": "10.0.0.0",
  "FullSemVer": "10.0.0",
  "InformationalVersion": "10.0.0+Branch.master.Sha.8947dafe06011c812599eb2b273830d916d367cf",
  "BranchName": "master",
  "EscapedBranchName": "master",
  "Sha": "8947dafe06011c812599eb2b273830d916d367cf",
  "ShortSha": "8947daf",
  "NuGetVersionV2": "10.0.0",
  "NuGetVersion": "10.0.0",
  "NuGetPreReleaseTagV2": "",
  "NuGetPreReleaseTag": "",
  "VersionSourceSha": "bf8dcfafbf235762f6e1d9396392dfac9ee690b6",
  "CommitsSinceVersionSource": 8,
  "CommitsSinceVersionSourcePadded": "0008",
  "UncommittedChanges": 327,
  "CommitDate": "2024-07-18"
}

which is correct - the package is unchanged.

If I try the suggested migration for 6.0.0, using trunk-based, I get completely different behaviour, so I'm querying - is there actually a 1:1 expected configuration for the above? Is the migration configuration advice incomplete or perhaps yielding assumptions?

workflow: TrunkBased/preview1
assembly-versioning-scheme: MajorMinor

GitVersion 6.0.0 gives me 10.0.8:

JSON

{
  "AssemblySemFileVer": "10.0.8.0",
  "AssemblySemVer": "10.0.0.0",
  "BranchName": "master",
  "BuildMetaData": null,
  "CommitDate": "2024-07-18",
  "CommitsSinceVersionSource": 1,
  "EscapedBranchName": "master",
  "FullBuildMetaData": "Branch.master.Sha.8947dafe06011c812599eb2b273830d916d367cf",
  "FullSemVer": "10.0.8",
  "InformationalVersion": "10.0.8+Branch.master.Sha.8947dafe06011c812599eb2b273830d916d367cf",
  "Major": 10,
  "MajorMinorPatch": "10.0.8",
  "Minor": 0,
  "Patch": 8,
  "PreReleaseLabel": "",
  "PreReleaseLabelWithDash": "",
  "PreReleaseNumber": null,
  "PreReleaseTag": "",
  "PreReleaseTagWithDash": "",
  "SemVer": "10.0.8",
  "Sha": "8947dafe06011c812599eb2b273830d916d367cf",
  "ShortSha": "8947daf",
  "UncommittedChanges": 328,
  "VersionSourceSha": "f327e3cc4c5b92b77dd186198d2bb4262c1473fd",
  "WeightedPreReleaseNumber": 60000
}

which is incorrect; the package hasn't changed so the version should not have done so either.

What is the migration path to yield original behaviour? My expectation is that the versioning should be driven by the last tag, particularly since the interposed commits are all marked with the none semver message.

I cannot find any up-to-date documentation on either Mainline as a strategy (or indeed what any of the strategies actually do), and the documented TrunkBased strategy does not appear to exist.

Assistance/advice would be appreciated. I am suspecting I need to replace strategies but since I clearly don't grasp what these are actually doing, I would like some help in understanding the functionality.

What I am attempting to achieve:

• I want a trunk-based approach where the last-seen tag on one of the trunk branches is used to determine the next version
• If master was last tagged with 1.2.0, then absent any other commit messaging, the next version should be 1.2.1 i.e. defaulting to a patch; if the next commit contains +semver: feature then it should yield 1.3.0; our build system will then apply a tag accordingly
• We use +semver: none to indicate that the version should not change, and correspondingly no tag should be added
• Hypothetically if a tag were to be skipped (a build breakage of some kind) then it is preferred if the versioning scheme recognised the gap i.e. the following should still work
  • Commit A (v1.2.0)
  • Commit B +semver: none (no tag)
  • Commit C (no tag but should have been v1.2.1)
  • Commit D (v1.2.2)
  • Thus rebuilding C should still yield the right tag
• If a support branch was last tagged with 1.3.2 then the next version should be 1.3.3
• Any other branches/PRs should be a pre-release of some kind

[arturcic]

@HHobeck can you help here?

[hotchkj]

@HHobeck still in Legal land at present 😞 it can be a slow process

[koppor]

Since the update of https://github.com/gittools/actions, this becomes more important again. May I ping you @hotchkj regarding the legal paper work? I was with Mercedes-Benz AG (we won an award regarding our training) and Nokia Bell Labs, maybe, I can assist.

[hotchkj]

@koppor to be clear, the paperwork is on my side for contributions - if anyone wants to tackle restoring the mainline functionality to GitVersion, they needn't wait on me per se. I can also test changes vs our current process easily enough, it's the signoff from legal on what I can spend time on coding that prevents my contributing.

[koppor]

it's the signoff from legal on what I can spend time on coding that prevents my contributing.

I worked with legal in my former roles and therefore I offered support. I can also connect to some other open source experts if it needs to be with more formal roles (in addition to experience). This is what I meant to offer.

[koppor]

@hotchkj we send you some energy for the legal paperwork

[strickie]

@hotchkj / @koppor What did you end up doing?
We are figthing (a loosing) battle with GitVersion v6 - Every try we have attempted, is just a litlle off. Almosy every on of our hundreds repos have a little somthing each, that make a common strategy almost impossible... :-(
Any help is much appreciated.

[koppor]

Still on my TODO list - we seem to have messed up 10 years ago when introducing GitButler - config at https://github.com/JabRef/jabref/blob/main/GitVersion.yml

I have some Claude subscription and I plan to use it to work on this.

[HHobeck]

We are figthing (a loosing) battle with GitVersion v6 - Every try we have attempted, is just a litlle off. Almosy every on of our hundreds repos have a little somthing each, that make a common strategy almost impossible... :-(
Any help is much appreciated.

It sounds like you’re dealing with a lot of edge cases across repositories. Could you share a couple of concrete examples of what’s not working as expected? Are you looking for the feature #4144?