[ISSUE] Incorrect output for assembly-informational-version

[phatcher]

Prerequisites

• I have written a descriptive issue title
• I have searched issues to ensure it has not already been reported

GitVersion package

GitVersion.Tool

GitVersion version

6.4

Operating system

Windows

What are you seeing?

I'm trying to update my build pipeline to use GitVersion6 and have the following gitversion.yml file

workflow: GitHubFlow/v1
mode: ContinuousDelivery
branches:
    main:
        mode: ContinuousDeployment
        label: ''
    release:
        label: ''
assembly-informational-format: '{AssemblySemVer} {ShortSha}'
ignore:
    sha: []

As we don't have NugetVersion2 anymore I was trying to update the assembly-informational-format to produce the same value as under V5.

What is expected?

I'd expect to get 6.13.54-gv60002 as the InformationalVersion

Steps to Reproduce

So invoking on my gv6 branch with

dotnet-gitversion /overrideconfig assembly-informational-format="{MajorMinorPatch}{PreReleaseLabelWithDash}{CommitsSinceVersionSource:0000}"

I get

{
  "AssemblySemFileVer": "6.13.54.0",
  "AssemblySemVer": "6.13.54.0",
  "BranchName": "feature/gv6",
  "BuildMetaData": 2,
  "CommitDate": "2025-08-12",
  "CommitsSinceVersionSource": 2,
  "EscapedBranchName": "feature-gv6",
  "FullBuildMetaData": "2.Branch.feature-gv6.Sha.489a0c0ab425214def918e36399f3cc3c9a9c42d",
  "FullSemVer": "6.13.54-gv6.1+2",
  "InformationalVersion": "6.13.54-gv60002",
  "Major": 6,
  "MajorMinorPatch": "6.13.54",
  "Minor": 13,
  "Patch": 54,
  "PreReleaseLabel": "gv6",
  "PreReleaseLabelWithDash": "-gv6",
  "PreReleaseNumber": 1,
  "PreReleaseTag": "gv6.1",
  "PreReleaseTagWithDash": "-gv6.1",
  "SemVer": "6.13.54-gv6.1",
  "Sha": "489a0c0ab425214def918e36399f3cc3c9a9c42d",
  "ShortSha": "489a0c0",
  "UncommittedChanges": 0,
  "VersionSourceSha": "21d7e26e6ff58374abd3daf2177be4b7a9c49040",
  "WeightedPreReleaseNumber": 30001
}

I also want this to work correctly on the main branch so I changed the call to take advantage of the new C# formatting

dotnet-gitversion /config gitversion-new.yml /overrideconfig assembly-informational-format="{MajorMinorPatch}{PreReleaseLabelWithDash}{CommitsSinceVersionSource:0000;;''}"

which produces

{
  "AssemblySemFileVer": "6.13.54.0",
  "AssemblySemVer": "6.13.54.0",
  "BranchName": "feature/gv6",
  "BuildMetaData": 2,
  "CommitDate": "2025-08-12",
  "CommitsSinceVersionSource": 2,
  "EscapedBranchName": "feature-gv6",
  "FullBuildMetaData": "2.Branch.feature-gv6.Sha.489a0c0ab425214def918e36399f3cc3c9a9c42d",
  "FullSemVer": "6.13.54-gv6.1+2",
  "InformationalVersion": "6.13.54-gv6-CommitsSinceVersionSource-0000-----",
  "Major": 6,
  "MajorMinorPatch": "6.13.54",
  "Minor": 13,
  "Patch": 54,
  "PreReleaseLabel": "gv6",
  "PreReleaseLabelWithDash": "-gv6",
  "PreReleaseNumber": 1,
  "PreReleaseTag": "gv6.1",
  "PreReleaseTagWithDash": "-gv6.1",
  "SemVer": "6.13.54-gv6.1",
  "Sha": "489a0c0ab425214def918e36399f3cc3c9a9c42d",
  "ShortSha": "489a0c0",
  "UncommittedChanges": 0,
  "VersionSourceSha": "21d7e26e6ff58374abd3daf2177be4b7a9c49040",
  "WeightedPreReleaseNumber": 30001
}

RepositoryFixture Test

No response

Output log or link to your CI build (if appropriate).

[arturcic]

I suspect this is kinda duplicate of #4652

[9swampy]

This appears to be a regression issue, not a duplicate.

dotnet-gitversion /overrideconfig assembly-informational-format="{MajorMinorPatch}{PreReleaseLabelWithDash}{CommitsSinceVersionSource:0000;;''}"

The problem is the ;;'' syntax. The new custom formatting changes don't support the old .NET composite format conditional syntax {value:format;;fallback}.

Analysis

The ;;'' syntax is standard .NET composite formatting where:

• First section: positive numbers
• Second section: negative numbers
• Third section: zero values (the empty string '' here)

But the new formatting system uses ?? fallback syntax instead of the traditional ;; sections.

Issue

This breaks existing configurations that use standard .NET formatting patterns. The new regex causes these tokens to be treated as literal text instead of being processed.

Solutions

1. Support both ;; and ?? syntax for backward compatibility
2. Make parsing more permissive for unrecognized format specifiers
3. Better error messages instead of silently outputting literal text

This is a backward compatibility break that should be fixed rather than closed as duplicate.

[9swampy]

I'll make some time to dig in to this tomorrow. Any guidance on options/preferred routes forward welcome.

Is this feeling like a roll-back and breathe or a fix forward please? The first red-green-refactor "fix" was a fair cop, but the expanding regression failures were a reality check.

I'd propose the fix-forward route to be a reset that tries to define a baseline of relevant coverage by taking the second green back to the start and converging on keeping that green with the custom format addition? Would that in your wisdom suffice; or have I poked a hornet's nest?

Maybe rollback and reset's the wise option?

[asbjornu]

Sorry, but I don't quite understand what you're suggesting @9swampy. I think what you've done so far in #4657 looks good, but the failing tests are of course a concern. Are they proving too difficult to fix that you are considering restarting the whole implementation?

[9swampy]

Appreciate the comments on the hasty attempt to investigate and resolve. I guess I was asking for a sanity check from someone more familiar with the codebase that I wasn't circling down an unsound path. Will try to get to the bottom of the regressions tomorrow. Thx.