The library's version lives in four properties in
QrCodeGenerator/QrCodeGenerator.csproj:
Version, PackageVersion, FileVersion, AssemblyVersion. Between releases it
carries a -dev prerelease suffix (e.g. 3.1.0-dev) so it's always ordered above the
last release but never resolved by a floating 3.* PackageReference (NuGet excludes
prereleases from floating ranges by default). README.md, QrCodeGenerator/docs/README.md,
and the demo projects' PackageReference versions stay pinned to the last published
release at all times — they're only updated as part of a release, never in between.
- Update
QrCodeGenerator/QrCodeGenerator.csproj: setVersion,PackageVersion,FileVersion(but notAssemblyVersion) to the release versionX.Y.Z(drop the-devsuffix), and updatePackageReleaseNotes. - Update
README.md: install command and any prose version references →X.Y.Z. - Update
QrCodeGenerator/docs/README.mdthe same way, including its.../blob/vX.Y.Z/...tag-pinned links. - Commit as
Release vX.Y.Z, tag the commitvX.Y.Z, push commit and tag. dotnet pack -c Releaseand publish the resulting nupkg to nuget.org (manual today).- Bump
QrCodeGenerator/QrCodeGenerator.csprojto the next planned version with a-devsuffix (e.g.3.2.0-dev), commit asBump version to 3.2.0-dev for development. LeaveREADME.md,QrCodeGenerator/docs/README.md, and the demo projects untouched — they keep pointing atX.Y.Zuntil the next release.
.github/workflows/demos.yaml packs the current source into a local NuGet feed and,
before building each demo, overrides that demo's resolved package version for the CI
run only (dotnet add package ... --source Local, which rewrites the checked-out
.csproj in the runner's workspace — nothing is committed). This means CI always
validates the examples against the in-progress library code, even though the
PackageReference version committed to the repo stays pinned to the last release.