Question

Your team publishes a shared .NET library to a NuGet feed using GitHub Actions. Product owners require that every release strictly follows Semantic Versioning (SemVer 2.0.0), and that stable production versions are only published when a maintainer creates an annotated Git tag like v2.4.0. Merges to the main branch should still produce consumable prerelease packages for internal testing, but these must never be treated as stable by consumers who pin to stable ranges. Which approach best satisfies these requirements?

Accepted Answer

Use a workflow triggered by both push to main and tag push; on main-branch runs append a prerelease label such as 2.5.0-beta.<run_number>, and on tag pushes matching v* strip the prerelease label and publish the stable version from the tag.

Answer

Trigger the publish job on push to main, deriving the version from the run number (e.g., 1.0.<run_number>), and manually edit the .csproj version before creating a production release.

Answer

Publish every merge to main as a stable version using build metadata (e.g., 2.5.0+<sha>), since build metadata identifies the commit and consumers can distinguish builds.

Answer

Trigger publishing only on tag pushes matching v*, and require developers to also push a tag for every internal test build so all packages share the same versioning path.