Libraries

Wed, 21 Oct 2026 17:55:00 +0000

Code that more than one project needs becomes a package. Mine are .NET libraries, published as NuGet packages to two places: nuget.org, where anyone finds them, and GitHub Packages, next to their source.

Concern	Choice
Package format	NuGet, or the language’s own format elsewhere
Primary feed	nuget.org
Secondary feed	GitHub Packages
Publishing	GitHub Actions, on a version tag
Versioning	Semantic versioning

Package metadata

The project file describes the package, so dotnet pack produces a complete .nupkg with its symbols alongside:

Git Tags: Naming the Commits That Matter

Wed, 21 Oct 2026 12:00:00 +0000

Branches move: every commit on main moves main forward. Sometimes you need a name that stays where it is put, such as “the commit that went out as version 1.6.0”. That is a tag. Tags mark releases, the build a bug report refers to, or the last commit before a large refactor, and almost every release tool, from GitHub Releases to package registries, reads them.

Tags look simple, and mostly are. The parts that cause trouble are the two kinds of tag, which behave differently in some commands, and the fact that tags are not pushed, fetched or overwritten the way branches are. This article covers both. The commands shown were run with Git 2.56 on 21 October 2026, in a scratch repository and in this site’s own repository. Long temporary paths in the output are left out.

Versioning on Artur Rios Lab

Libraries

Package metadata

Git Tags: Naming the Commits That Matter