Release Checklist

This section documents MSBuild 18.9, the .NET SDK 10.0.402 (with its dotnet CLI) and NuGet 7.9, as published in the MSBuild, .NET and NuGet documentation on learn.microsoft.com, which is the reference these pages are written and verified against. Material about .NET 11 / NuGet 8.0 is still in preview and is always flagged as such — never presented as baseline.

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

The C# Reference bibliography lists the reference material consulted while preparing these pages.

This checklist condenses the publishing group into the questions to answer before every release of a library such as Ledgerline. It assumes .NET SDK 10.0.402 (NuGet 7.9.0) or later; each item links to the page that explains it and shows the commands. The first release needs all of it; later releases mostly the Build, Checks and Publish sections.

Design

  • Target frameworks chosen: a net8.0-or-later target, netstandard2.0 only for reach, net462 only if .NET Framework users need it; no netstandard1.x (Choosing target frameworks).

  • The same public API on every compatible framework (Compatibility rules).

  • Dependencies reviewed: few, with minimum versions only — no exact versions, no upper bounds; polyfills only on older frameworks; build-time packages PrivateAssets="all" (Dependencies).

  • Breaking changes classified (source, behaviour, binary) and reflected in the version (Breaking changes).

  • Strong naming decided once — and the key never changed (Strong naming).

Metadata

  • PackageId unique, at most 100 characters, under a reserved prefix if possible (ID prefix reservation).

  • Authors, Description, Copyright, PackageProjectUrl, PackageTags and PackageReleaseNotes set — not the defaults (The properties).

  • README packed (PackageReadmeFile), images only from allowed domains (The README).

  • Icon embedded (PackageIcon, PNG or JPEG, 128×128, under 1 MB) (The icon).

  • Licence as an SPDX expression or a packed file — never PackageLicenseUrl (The licence).

Build

  • Version chosen by SemVer; prerelease label for anything not stable; no stable package depending on a prerelease (NU5104) (Versioning and Prerelease Packages).

  • AssemblyVersion policy applied consistently; InformationalVersion left to the SDK.

  • Source Link working (sourcelink.json in the PDB, <repository commit=...> in the .nuspec); no extra Source Link package on SDK 8+ (Source Link).

  • Symbols shipped: .snupkg or embedded PDBs (Symbol packages).

  • Built in CI with ContinuousIntegrationBuild=true, a locked restore and the SDK from global.json (CI Release Workflows).

Checks

  • EnablePackageValidation with PackageValidationBaselineVersion set to the last release; any suppression reviewed (Package Validation and API Compatibility).

  • Package contents inspected: lib/ folders and dependency groups match; no stray files; no NU5xxx warnings left unexplained (Pack and Push Errors).

  • dotnet-validate package local reports Source Link, determinism and compiler flags as valid.

  • Installed from a test feed (a folder or BaGetter) into a clean consumer for each supported framework family, restored with --no-http-cache (Multi-targeted packages).

  • Optionally pushed to int.nugettest.org to see nuget.org’s validation and rendering (Integration gallery).

Publish

  • Trusted Publishing policy on nuget.org for the repository, workflow file and environment — or, failing that, a scoped API key that expires within 30 days (Trusted Publishing, Scoped API keys).

  • Release started by a tag; build and push in separate jobs; only the push job has id-token: write.

  • --skip-duplicate on the push so a re-run is safe.

  • If the account registered a signing certificate: packages author-signed and timestamped (Signing Packages).

  • Validation and indexing finished (usually under 15 minutes); the package page shows the README, icon, licence and repository link.

After the release

  • Release notes and documentation updated; e-mail notifications for new versions enabled on the account.

  • Dependencies watched: NuGetAudit warnings in CI, updates of vulnerable transitive packages (Auditing Packages for Vulnerabilities).

  • A broken or vulnerable version deprecated (with an alternative) and unlisted; a vulnerability reported to the GitHub Advisory Database once the fix is out (Managing Published Packages).

  • Package validation baseline moved to the new version, and old suppressions removed.

Source: Open-source library guidance, Package authoring best practices, Best practices for a secure software supply chain.

References