Principle:Kubeflow Kubeflow Release Planning
| Knowledge Sources | |
|---|---|
| Domains | Release Management, Project Coordination, Open Source Governance |
| Last Updated | 2026-02-13 00:00 GMT |
Overview
Release Planning is the process of coordinating quarterly releases across all Kubeflow Working Groups, establishing timelines, assembling release teams, and creating tracking infrastructure to ensure a cohesive platform release.
Description
Kubeflow operates as a collection of sub-projects (Trainer, KServe, Katib, Pipelines, Model Registry, Spark Operator, and others) maintained by independent Working Groups (WGs). Release Planning provides the coordination layer that aligns these sub-projects into a unified platform release on a quarterly cadence. The process follows the Release Handbook maintained in the kubeflow/community repository, which defines the roles, responsibilities, and timeline templates for each release cycle.
The release planning phase establishes the release version number (e.g., v1.11), recruits and assigns a release team from the community, creates a GitHub Project Board for cross-WG visibility, and opens per-WG tracking issues that anchor each group's contribution to the release. This phase transforms individual WG roadmaps and community priorities into a concrete, time-bound delivery plan.
Usage
Release Planning should be initiated:
- After the previous release has been completed and announced
- Approximately one quarter before the target release date
- When Working Groups have updated their individual roadmaps with planned features
- When sufficient community volunteers are available to staff the release team
Theoretical Basis
The release planning process follows a structured sequence:
Step 1: Determine Release Scope
Review community priorities, Working Group roadmaps, and feedback from the previous release. Identify the major themes that will define the upcoming release (e.g., "Trainer V2.0", "Model Registry new features").
Step 2: Establish Timeline
Using the Release Handbook template, define key milestones:
- Planning start date: When the release cycle officially begins
- Feature freeze date: Deadline for new feature merges
- Code freeze date: Deadline for all code changes except critical fixes
- Release candidate date: When RC builds are produced for testing
- Release date: Target date for the final release
Step 3: Assemble Release Team
Recruit volunteers from the community to fill release team roles:
- Release Lead: Overall coordination and decision-making
- Release Lead Shadow: Learning the process for future releases
- Per-WG Liaisons: Point of contact between the release team and each Working Group
- Documentation Lead: Coordinates documentation updates across sub-projects
Step 4: Create Tracking Infrastructure
- Create a GitHub Project Board for the release (e.g., "Kubeflow v1.11 Release")
- Open tracking issues in each sub-project repository
- Link all tracking issues to the central Project Board
- Update ROADMAP.md with the new release section and timeline reference
Step 5: Communicate the Plan
Share the release plan through community channels:
- Kubeflow community mailing list
- Kubeflow Slack workspace
- Working Group meeting agendas
The quarterly cadence ensures predictability for both contributors and users, while the structured roles and tracking infrastructure provide accountability and visibility throughout the release cycle.