Tags & pinning
Every image publishes several tags pointing at the same build. Which one you pin decides what happens when the software changes underneath you.
Pin by digest for immutability
A digest is content-addressed — it can never move. Preferred for production deployments.
FROM ghcr.io/rtvkiz/minimal-python@sha256:<digest>What each tag does
| Reference | Example | Behavior |
|---|---|---|
| Digest | minimal-python@sha256:… | Immutable content identity. Never moves. |
| Version | minimal-caddy:2.11.4-r0 | Moves when that application version is rebuilt with newer packages. |
| Dated version | minimal-caddy:2.11.4-r0-20260725 | Build-history tag; may move if rebuilt again on the same UTC date. |
| Minor line | minimal-caddy:2.11 | Newest patch within that minor line. |
| Major line | minimal-caddy:2 | Newest release within that major line. Does not cross a major bump. |
| Latest | minimal-caddy:latest | Newest production build, including across major versions. |
| Dev | minimal-caddy:latest-dev | Newest development/debug variant. |
Which should you pin?
Pin a major line (:2) if you want ongoing patches without being
moved across a breaking upstream release. :latest will cross a major
bump; an exact version tag never moves forward at all, so it stops receiving security fixes.
Pin a digest when you need a byte-identical artifact and will update it deliberately.
Every tag above has a -dev companion — :2-dev, :2.11-dev.
Two deliberate exceptions
- Images on a
0.xversion publish only the minor line (:0.42, never:0). Semantic versioning permits breaking changes between0.xminors, so a rolling:0would promise a compatibility guarantee that does not exist. - Calendar-versioned images (minio,
2025.10.15) publish no line tags — a:2025tag would imply a support line that is not a real thing.
About the epoch
The Melange epoch (-r0) resets on an upstream application-version bump,
and increments when the build recipe changes while the upstream version stays the same.