A consistent container image tagging convention across all kptdev repos that publish images (kpt, porch, and any others) should be used, so users know what they're pulling.
Proposal:
latest -> the latest dev build. Updated on every merge to main.stable -> the latest release. Updated on every non-prerelease GitHub Release.
Alongside those mutable tags we keep immutable vX.Y.Z tags for releases, so a released version can always be pinned. These are never re-pointed.
Pre-releases (alpha/beta/rc, or anything GitHub marks as a pre-release) publish their version tag but must NOT move stable.
Where we are today
| Repo (images) |
latest |
stable |
Version tag |
Dev build on merge to main |
kpt (ghcr.io/kptdev/kpt) |
no |
no |
yes |
no dedicated latest dev tag (release workflow runs on main + tags via GoReleaser) |
porch (ghcr.io/kptdev/porch-*) |
yes |
no |
yes |
yes (latest on each merge) |
krm-functions-catalog (ghcr.io/kptdev/*) |
yes |
no |
yes |
yes (latest on each merge) |
| krm-functions-sdk |
n/a |
n/a |
n/a |
n/a (library, no images) |
Re-pointing stable
Normally stable just follows the latest release automatically. If we ever need to roll it back to an older release, that should be a manual, permission-gated action by a maintainer.
Docs
Define the convention in one authoritative place rather than per-repo READMEs. The governance repo's VERSIONING.md already owns tag semantics (Floating Tags, Latest Tag, Best Practices), so the agreed convention should be updated there.
Note that this proposal changes the current policy: VERSIONING.md today defines latest as "the most recent release" (for testing/dev, not production) and has no stable tag. It uses floating vX.Y/vX tags for the latest release. So this is an amendment to that policy, and we should decide how stable relates to the existing floating tags.
Notes
- Older/existing images are left untouched - this only applies going forward.
- Once the terms are agreed, each repository should be validated/updated to follow the terms.
A consistent container image tagging convention across all kptdev repos that publish images (kpt, porch, and any others) should be used, so users know what they're pulling.
Proposal:
latest-> the latest dev build. Updated on every merge tomain.stable-> the latest release. Updated on every non-prerelease GitHub Release.Alongside those mutable tags we keep immutable
vX.Y.Ztags for releases, so a released version can always be pinned. These are never re-pointed.Pre-releases (alpha/beta/rc, or anything GitHub marks as a pre-release) publish their version tag but must NOT move
stable.Where we are today
lateststablemainghcr.io/kptdev/kpt)latestdev tag (release workflow runs on main + tags via GoReleaser)ghcr.io/kptdev/porch-*)lateston each merge)ghcr.io/kptdev/*)lateston each merge)Re-pointing stable
Normally
stablejust follows the latest release automatically. If we ever need to roll it back to an older release, that should be a manual, permission-gated action by a maintainer.Docs
Define the convention in one authoritative place rather than per-repo READMEs. The governance repo's VERSIONING.md already owns tag semantics (
Floating Tags,Latest Tag,Best Practices), so the agreed convention should be updated there.Note that this proposal changes the current policy: VERSIONING.md today defines
latestas "the most recent release" (for testing/dev, not production) and has nostabletag. It uses floatingvX.Y/vXtags for the latest release. So this is an amendment to that policy, and we should decide howstablerelates to the existing floating tags.Notes