Releases follow the pattern v{SEMVER}-{STADIUM} (e.g., v1.0.0-azteca). Codenames are drawn alphabetically from the stadium list of famous football stadiums that hosted FIFA World Cup matches.
Branch protection prevents direct pushes to master, so all release prep goes through a PR:
git checkout master && git pull
git checkout -b release/v1.0.0-aztecaMove items from [Unreleased] to a new release section in CHANGELOG.md:
# Move items from [Unreleased] to new release section
# Example: [1.0.0 - azteca] - 2026-01-22
git add CHANGELOG.md
git commit -m "docs: prepare changelog for v1.0.0-azteca release"
git push origin release/v1.0.0-azteca
# Open a PR, get it reviewed, and merge into masterBefore creating the tag, verify all of the following:
-
CHANGELOG.md[Unreleased]section is moved to a new versioned release entry -
dotnet build --configuration Releasepasses -
dotnet test --settings .runsettingspasses - Stadium name is valid and follows alphabetical order (see stadium list)
- All CI checks on
masterare green
After the PR is merged, create and push the version tag from master:
git checkout master && git pull
git tag -a v1.0.0-azteca -m "Release 1.0.0 - Azteca"
git push origin v1.0.0-aztecaPushing the tag triggers the CD workflow which automatically:
- Validates the stadium name
- Builds and tests the project in Release configuration
- Publishes Docker images to GitHub Container Registry with three tags
- Creates a GitHub Release with auto-generated changelog from commits
💡 Always update CHANGELOG.md before creating the tag. See CHANGELOG.md for the complete stadium list (A-Z) and release history.
Each release publishes multiple tags for flexibility:
# By semantic version (recommended for production)
docker pull ghcr.io/nanotaboada/dotnet-samples-aspnetcore-webapi:1.0.0
# By stadium name (memorable alternative)
docker pull ghcr.io/nanotaboada/dotnet-samples-aspnetcore-webapi:azteca
# Latest release
docker pull ghcr.io/nanotaboada/dotnet-samples-aspnetcore-webapi:latest