Principle:Kubeflow Kubeflow Release Tagging
| Knowledge Sources | |
|---|---|
| Domains | Release Management, Version Control, Container Registry |
| Last Updated | 2026-02-13 00:00 GMT |
Overview
Release Tagging is the practice of creating immutable version markers across all Kubeflow sub-project repositories and publishing corresponding container images, thereby producing the artifacts that constitute an official Kubeflow release.
Description
Kubeflow's distributed repository structure means that a platform release is not a single tag on a single repository. Instead, it is a coordinated set of tags across multiple sub-project repositories, each producing its own versioned artifacts (container images, Helm charts, CLI binaries). The Release Tagging principle defines how these tags are created, how container images are built and pushed to registries, and how GitHub Releases are published with appropriate changelogs and release notes.
The CHANGELOG.md in the main kubeflow/kubeflow repository explicitly notes that changelogs now live in the respective sub-project repositories. This reflects the decentralized nature of Kubeflow releases: each sub-project owns its version numbering, changelog generation, and release artifact production. The Release Tagging principle provides the coordination framework that ensures all sub-projects tag their releases in a consistent and timely manner.
Release Tagging is the culmination of the release management workflow. It occurs only after integration testing has passed, documentation has been updated, and the release team has given sign-off. Once tags are created, they are immutable and represent the official released versions.
Usage
Release Tagging should be performed:
- After all integration tests have passed on the manifests release candidate
- After ROADMAP.md and kubeflow.org documentation have been updated
- After the release team has formally signed off on the release
- When each sub-project Working Group has confirmed readiness to tag
- When container image build pipelines are ready to produce release artifacts
Theoretical Basis
The release tagging process follows a specific sequence to ensure consistency and correctness:
Tag Format Convention
All Kubeflow sub-projects follow semantic versioning with the format Template:Code (e.g., v0.15.2, v0.19.0). Some sub-projects may use different major version numbers reflecting their individual maturity (e.g., Pipelines uses 2.15.0). The tag format is:
- Prefix: The letter v followed by the version number
- Major: Incremented for breaking changes
- Minor: Incremented for new features
- Patch: Incremented for bug fixes
Tagging Sequence
- Sub-project tags first: Each Working Group tags its component release in its own repository
- Container images built: CI/CD pipelines triggered by tags build and push container images
- Manifests tag last: The kubeflow/manifests repository is tagged after all component images are available
- GitHub Releases created: Each sub-project publishes a GitHub Release with changelog and release notes
Container Image Tagging
Container images are tagged to match the git tag of the source code:
- Exact version tag: e.g., Template:Code
- Latest tag: Updated to point to the newest release image
- Registry: Images are pushed to the project's container registry
Changelog Generation
Since changelogs live in sub-project repositories (as noted in the main CHANGELOG.md), each Working Group is responsible for:
- Generating a changelog from git history since the previous release
- Highlighting breaking changes, new features, and bug fixes
- Including migration instructions for breaking changes
Immutability Guarantee
Once a tag is created and artifacts are published:
- Git tags must not be deleted or moved
- Container images must not be overwritten
- GitHub Releases must not be deleted
- Any corrections require a new patch release (e.g., v1.11.1)