"error : Version's parameters must be greater than or equal to zero." when setting versionHeightOffset negative

Opening a separate issue, because it appears that #703 is now resolved, but there is another seemingly unrelated problem.

We frequently set versionHeightOffset to a negative value to make the vNext the same as current version + 1 upon release. But it is no longer functioning with a negative value (in 3.5.68-alpha).

F:\Users\shad\.nuget\packages\nerdbank.gitversioning\3.5.68-alpha\build\Nerdbank.GitVersioning.Inner.targets(17,5): error : Version's parameters must be greater than or equal to zero.
F:\Users\shad\.nuget\packages\nerdbank.gitversioning\3.5.68-alpha\build\Nerdbank.GitVersioning.Inner.targets(17,5): error : Parameter name: revision

The configuration used was

{
  "$schema": "https://raw.githubusercontent.com/AArnott/Nerdbank.GitVersioning/master/src/NerdBank.GitVersioning/version.schema.json",
  "version": "0.5.0",
  "assemblyVersion": {
    "version": "0.4.1"
  },
  "versionHeightOffset": "-7",
  "publicReleaseRefSpec": [
    "^refs/heads/main$",
    "^refs/heads/master$",
    "^refs/heads/release/v\\d+\\.\\d+(?:\\.\\d+)?(?:\\.\\d+)?$",
    "^refs/tags/v\\d+\\.\\d+"
  ],
  "cloudBuild": {
    "buildNumber": {
      "enabled": true
    }
  },
  "release": {
    "branchName": "release/v{version}"
  }
}

I confirmed that setting versionHeightOffset to a positive value eliminates the error message, so there is some validation that didn’t exist in version 3.3.37 (the version we use in all of our other projects).

[NightOwl888]

Yea, I have tried semver 2, but that really doesn’t solve the issue with patching a ported component that is version-aligned with the Java version.

[AArnott]

FYI You can override any nbgv version property in msbuild you want using a custom msbuild target:

<Target Name="Set4ComponentNugetVersion" AfterTargets="GetBuildVersion">
  <PropertyGroup>
    <NuGetPackageVersion>$(YourCustomVersion)</NuGetPackageVersion>
  </PropertyGroup>
</Target>

The GetBuildVersion target unconditionally sets many properties, but by scheduling your target to run right after, you can re-set them to whatever you want. Then, when the msbuild target runs that sets the c# attributes for your assembly, it’ll use the values you defined.

I don’t object to a new setting to allow 4-component nuget versions to be computed automatically though. If it did, would it just pull all 4 components from the same version used for AssemblyFileVersion? Would that work for you?