fix: sync version.json with the actual release version, fixing every published NuGet version

Root cause of every "release worked but the wrong version got published" mystery
this whole project: Nerdbank.GitVersioning never derives the version number from
the git tag, even when it correctly detects a public-release tag - it always
computes from version.json's own "version" field. That field had sat at
"0.1-alpha" unchanged since the first commit, so every release.yml run (v0.1.0
through v0.10.0) published an unrelated 0.1.x-alpha prerelease to NuGet.org
instead of its real tagged version.

Verified locally: with version.json at "0.1-alpha", nbgv get-version at the
exact v0.10.0-tagged commit reports PublicRelease: true but still computes
"0.1.69-alpha". Bumping version.json's "version" to the real current version
(a full three-component "0.10.0", not just "0.1") makes it compute exactly
"0.10.0" at that same commit - confirmed with a throwaway test commit/tag.

Also wires release-please-config.json's extra-files to update version.json's
"version" field automatically on every future release commit, so the two
version sources can't drift apart again. fetch-tags: true added to both
workflows' checkout steps as a defensive addition (not the actual cause here,
but the standard NBGV+GitHub Actions recommendation regardless).

Author: GREENFONTS

.github/workflows/ci.yml

@@ -15,6 +15,7 @@ jobs:
       - uses: actions/checkout@v7
         with:
           fetch-depth: 0 # full history - Nerdbank.GitVersioning needs it to compute the version
+          fetch-tags: true # belt-and-braces so a tagged commit's tags are always visible to NBGV
 
       - uses: actions/setup-dotnet@v5
         with:

.github/workflows/release.yml

@@ -21,6 +21,7 @@ jobs:
       - uses: actions/checkout@v7
         with:
           fetch-depth: 0
+          fetch-tags: true # belt-and-braces so a tagged commit's tags are always visible to NBGV
 
       - uses: actions/setup-dotnet@v5
         with:

CHANGELOG.md

@@ -20,6 +20,7 @@ own version is independent of Monnify's API versioning.
 
 * envelope handling now tolerates endpoints (e.g. paycodes) that omit `requestSuccessful` from their response
 * a non-JSON error body (e.g. a proxy/gateway's own error page for a 502/504) on a failing HTTP status now throws `MonnifyApiException` with the real status code, instead of a misleading `MonnifyDeserializationException` — found via a real sandbox 502 while dogfooding the published package before v1
+* `version.json`'s Nerdbank.GitVersioning baseline had sat at `0.1-alpha` since the very first commit and was never kept in sync with the actual released version. NBGV only reads the version *number* from `version.json` itself - it never derives it from the git tag, even when it correctly detects a public-release tag - so every release published so far (`v0.1.0` through `v0.10.0`) actually shipped to NuGet.org as an unrelated `0.1.x-alpha` prerelease instead of its real tagged version. Fixed by bumping `version.json` to the real current version and wiring `release-please-config.json`'s `extra-files` to keep it in sync automatically on every future release, so this can't drift out of sync again
 
 ## [0.5.0](https://github.com/Monnify/monnify-dotnet-lib/compare/v0.4.0...v0.5.0) (2026-06-30)
 

release-please-config.json

@@ -4,7 +4,14 @@
   "packages": {
     ".": {
       "release-type": "simple",
-      "changelog-path": "CHANGELOG.md"
+      "changelog-path": "CHANGELOG.md",
+      "extra-files": [
+        {
+          "type": "json",
+          "path": "version.json",
+          "jsonpath": "$.version"
+        }
+      ]
     }
   }
 }

version.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://raw.githubusercontent.com/dotnet/Nerdbank.GitVersioning/main/src/NerdBank.GitVersioning/version.schema.json",
-  "version": "0.1-alpha",
+  "version": "0.10.0",
   "publicReleaseRefSpec": [
     "^refs/tags/v\\d+\\.\\d+\\.\\d+$"
   ],