A release without a tag is a rumor. A release with a careless tag is a future incident. Tags are the ledger of what actually shipped, and they should be boring, consistent, and impossible to misread.
Why tags are the release backbone
Tags do three things no other artifact can:
- Pin the exact commit that shipped.
- Anchor release notes to a stable identifier.
- Create a searchable audit trail months later.
If your tags are inconsistent, every other system on top of them becomes fragile.
The minimum viable tagging policy
1) Choose a single naming convention
Most teams use semantic versions (v1.8.2). If you can't use semver, at least
choose a strict pattern (release-2026.01.16). The important part is never
mixing conventions.
2) Prefer annotated tags
Annotated tags store a message, author, and date--use them. Lightweight tags are fine for local experiments, but releases deserve context.
git tag -a v1.8.2 -m "Release: v1.8.2"
3) Tag from the release branch, not from memory
Cut the tag from the exact commit that passed CI. Never tag "what you think merged." A tag should be created after the final merge and after CI passes.
4) Treat tags as immutable
If you have to delete and recreate a tag, something went wrong. Use a new version instead. Your audit trail is only trustworthy if tags never move.
Map every tag to an artifact set
Tags should resolve to a small bundle of evidence:
- Build or container ID
- Release note URL
- Deployment record
- Feature flag snapshot
If you can’t find these within five minutes, your tag policy needs more automation.
Common tag failure modes (and fixes)
- Tag created before CI passes: block tag creation in CI until the final pipeline is green.
- Tag created on the wrong branch: require tags from the release branch only.
- Tag missing a message: enforce annotated tags with a short commit hook.
A release-tag checklist
- Version is predictable and matches the changelog.
- Tag is annotated and includes a release message.
- Tag points to the same commit referenced by the release notes.
- CI artifacts (builds, containers) are linked to the tag.
Tags as a communication surface
A tag is a quiet announcement. It should map directly to the release notes and any user-facing communication. When support asks, "What shipped?" the answer should be a tag and its notes, not a Slack thread.
How ReleaseMind uses tags
ReleaseMind treats tags as the spine of a release. We use them to draft notes, build a timeline, and publish a narrative that matches the commit. The result is a release that can be understood months later, not just the day it shipped.
