Workflow:Kubeflow Kubeflow Release Management
| Knowledge Sources | |
|---|---|
| Domains | Release_Engineering, Governance, MLOps |
| Last Updated | 2026-02-13 14:00 GMT |
Overview
Coordinated quarterly release process for the Kubeflow AI platform, synchronizing deliverables across all Working Groups and sub-project repositories.
Description
This workflow describes how Kubeflow manages its quarterly major releases across the distributed project structure. Each release is coordinated by a dedicated Release Team following the Release Handbook maintained in the kubeflow/community repository. The process involves theme identification, feature planning across Working Groups, cross-project testing, documentation updates, and synchronized version tagging. Sub-project repositories (Pipelines, Trainer, Katib, KServe, Notebooks, Manifests, Model Registry, Spark Operator) each produce independent version releases that are bundled into the overall Kubeflow platform release.
Usage
Follow this workflow when you are a Kubeflow release team member coordinating a quarterly release, a Working Group lead planning deliverables for an upcoming release, or a contributor who needs to understand the release timeline and process for landing features.
Execution Steps
Step 1: Release_Planning
Form the release team and establish the timeline, themes, and feature scope for the upcoming release. The release team is assembled from community volunteers and follows the Release Handbook in kubeflow/community. Each Working Group identifies their deliverables and creates tracking issues.
Key considerations:
- Release team roles are defined in the community repository
- The Release Handbook provides the standard operating procedure
- Themes are identified based on community priorities and CNCF roadmap alignment
- Each Working Group creates a tracking issue listing planned features and fixes
- A GitHub Project Board tracks high-level deliverables across all groups
Step 2: Feature_Development
Working Groups develop their planned features in their respective sub-project repositories. Each sub-project operates independently with its own version numbering, CI/CD, and release cadence, but coordinates with the platform release timeline for integration milestones.
Key considerations:
- Sub-project versions are independent of the Kubeflow platform version
- Features must be merged before the feature freeze date
- Breaking changes require cross-Working Group communication
- CI/CD pipelines in each repository validate changes continuously
Step 3: Integration_Testing
Perform cross-project integration testing to verify that all sub-project releases work together. This includes deploying the full platform using the updated kubeflow/manifests and running end-to-end tests that exercise workflows spanning multiple components.
Key considerations:
- Manifests repository is the integration point for all sub-projects
- End-to-end tests validate the build-train-deploy lifecycle
- Compatibility between sub-project versions must be verified
- Security scanning (CVE) is performed on all container images
Step 4: Documentation_Update
Update the Kubeflow documentation on kubeflow.org to reflect new features, changed APIs, and updated installation instructions. Each Working Group is responsible for documenting their changes, and the release team coordinates the overall release notes.
Key considerations:
- Each Working Group updates docs for their sub-project changes
- The ROADMAP.md in kubeflow/kubeflow is updated with the new release section
- Release blog post is prepared for the Kubeflow blog
- Migration guides are provided for breaking changes
Step 5: Release_Tagging
Create release tags across all sub-project repositories and the manifests repository. The release team coordinates the tagging to ensure version consistency. Release artifacts (container images, Helm charts, kustomize manifests) are published to their respective registries.
Key considerations:
- Each sub-project tags its own release version
- The kubeflow/manifests repository tags the platform release version
- Container images are pushed to the official container registry
- Release notes aggregate changes from all Working Groups
- The CHANGELOG.md is updated (historically in kubeflow/kubeflow, now per sub-project)
Step 6: Post_release_Communication
Announce the release to the community and wider ecosystem. This includes publishing the blog post, updating the Kubeflow website, notifying Slack channels, and communicating with Packaged Distribution vendors so they can update their offerings.
Key considerations:
- Blog post published on blog.kubeflow.org
- Slack announcement in the Kubeflow workspace
- CNCF communication for ecosystem visibility
- Packaged Distribution vendors notified to update their builds
- Community meeting presentation to walk through highlights