From 878990173dfef8d34974783fbe44d01812cf69a6 Mon Sep 17 00:00:00 2001 From: mgravell Date: Thu, 10 Sep 2026 15:47:58 +0100 Subject: [PATCH] Fix tag-triggered releases: accept unprefixed tags, keep 3.2.0 reachable The 3.2.0 release failed its "Verify tag matches computed version" guard with "Tag '3.2.0' does not match the computed version '3.2.0-g8460293104'". Cause: publicReleaseRefSpec still carried the v2-era "^refs/tags/v\d+\.\d+". The whole v3 line tags without the "v" (3.0.0 ... 3.1.31, 3.2.0), so on a release event - where GITHUB_REF is refs/tags/3.2.0 - nbgv did not consider the build a public release and appended the "-g" suffix. This never bit us before because release.yml is new (#3213); every earlier v3 package was pushed from a main build, where the refspec did match. The stray 3.1.1-g7441909d06 on nuget.org is the same failure mode escaping under the old pipeline. Relax the refspec to "^refs/tags/v?\d+\.\d+" so both spellings are public. Because this commit adds to the commit height, drop versionHeightOffset to -3 so the release commit still computes as 3.2.0 rather than skipping to 3.2.1. versionHeightOffsetAppliesTo is already "3.2", so the height is not reset. Verified with nbgv on this commit: refs/tags/3.2.0, refs/tags/v3.2.0 and refs/heads/main all compute NuGetPackageVersion 3.2.0. --- version.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/version.json b/version.json index b4dadd52f..4644dced5 100644 --- a/version.json +++ b/version.json @@ -1,12 +1,12 @@ { "version": "3.2", - "versionHeightOffset": -2, + "versionHeightOffset": -3, "versionHeightOffsetAppliesTo": "3.2", "assemblyVersion": "3.0", "publicReleaseRefSpec": [ "^refs/heads/main$", "^refs/heads/v[0-9]+$", - "^refs/tags/v\\d+\\.\\d+" + "^refs/tags/v?\\d+\\.\\d+" ], "nugetPackageVersion": { "semVer": 2