Kubernetes Release Cycle

Targeting enhancements, Issues and PRs to Release Milestones

This document is focused on Kubernetes developers and contributors who need to create an enhancement, issue, or pull request which targets a specific release milestone.

The process for shepherding enhancements, issues, and pull requests into a Kubernetes release spans multiple stakeholders:

  • the enhancement, issue, and pull request owner(s)
  • SIG leadership
  • the

Information on workflows and interactions are described below.

As the owner of an enhancement, issue, or pull request (PR), it is your responsibility to ensure release milestone requirements are met. Automation and the Release Team will be in contact with you if updates are required, but inaction can result in your work being removed from the milestone. Additional requirements exist when the target milestone is a prior release (see cherry pick process for more information).

TL;DR

If you want your PR to get merged, it needs the following required labels and milestones, represented here by the Prow /commands it would take to add them:

Normal Dev (Weeks 1-8)

  • /sig {name}
  • /kind {type}
  • /lgtm
  • /approved

  • /milestone {v1.y}
  • /sig {name}
  • /kind {bug, failing-test}
  • /lgtm
  • /approved

Post-Release (Weeks 11+)

Return to 'Normal Dev' phase requirements:

  • /sig {name}
  • /kind {type}
  • /lgtm
  • /approved

Merges into the 1.y branch are now via cherry picks, approved by .

In the past, there was a requirement for a milestone-targeted pull requests to have an associated GitHub issue opened, but this is no longer the case. Features or enhancements are effectively GitHub issues or

The general labeling process should be consistent across artifact types.

Definitions

The Release Cycle

Image of one Kubernetes release cycle

Kubernetes releases currently happen approximately four times per year.

The release process can be thought of as having three main phases:

  • Enhancement Definition
  • Implementation
  • Stabilization

But in reality, this is an open source and agile project, with feature planning and implementation happening at all times. Given the project scale and globally distributed developer base, it is critical to project velocity to not rely on a trailing stabilization phase and rather have continuous integration testing which ensures the project is always stable so that individual commits can be flagged as having broken something.

With ongoing feature definition through the year, some set of items will bubble up as targeting a given release. starts ~4 weeks into release cycle. By this point all intended feature work for the given release has been defined in suitable planning artifacts in conjunction with the Release Team's .

After Enhancements Freeze, tracking milestones on PRs and issues is important. Items within the milestone are used as a punchdown list to complete the release. On issues, milestones must be applied correctly, via triage by the SIG, so that

There is some automation in place to help automatically assign milestones to PRs.

This automation currently applies to the following repos:

  • kubernetes/enhancements
  • kubernetes/kubernetes
  • kubernetes/release
  • kubernetes/sig-release
  • kubernetes/test-infra

At creation time, PRs against the master branch need humans to hint at which milestone they might want the PR to target. Once merged, PRs against the master branch have milestones auto-applied so from that time onward human management of that PR's milestone is less necessary. On PRs against release branches, milestones are auto-applied when the PR is created so no human management of the milestone is ever necessary.

Any other effort that should be tracked by the Release Team that doesn't fall under that automation umbrella should be have a milestone applied.

Implementation and bug fixing is ongoing across the cycle, but culminates in a code freeze period.

There are approximately two weeks following Code Freeze, and preceding release, during which all remaining critical issues must be resolved before release. This also gives time for documentation finalization.

When the code base is sufficiently stable, the master branch re-opens for general development and work begins there for the next release milestone. Any remaining modifications for the current release are cherry picked from master back to the release branch. The release is built from the release branch.

Each release is part of a broader Kubernetes lifecycle:

Image of Kubernetes release lifecycle spanning three releases

Removal Of Items From The Milestone

Before getting too far into the process for adding an item to the milestone, please note:

Members of the

Members of the Release Team may remove PRs from the milestone for any of the following, or similar, reasons:

While members of the Release Team will help with labelling and contacting SIG(s), it is the responsibility of the submitter to categorize PRs, and to secure support from the relevant SIG to guarantee that any breakage caused by the PR will be rapidly resolved.

Where additional action is required, an attempt at human to human escalation will be made by the Release Team through the following channels:

Adding An Item To The Milestone

Milestone Maintainers

The members of the GitHub team are entrusted with the responsibility of specifying the release milestone on GitHub artifacts.

This group is by SIG Release and has representation from the various SIGs' leadership.

Feature additions

Feature planning and definition takes many forms today, but a typical example might be a large piece of work described in a

For the first ~4 weeks into the release cycle, the Release Team's Enhancements Lead will interact with SIGs and feature owners via GitHub, Slack, and SIG meetings to capture all required planning artifacts.

If you have an enhancement to target for an upcoming release milestone, begin a conversation with your SIG leadership and with that release's Enhancements Lead.

Issue additions

Issues are marked as targeting a milestone via the Prow "/milestone" command.

The Release Team's and overall community watch incoming issues and triage them, as described in the contributor guide section on issue triage.

Marking issues with the milestone provides the community better visibility regarding when an issue was observed and by when the community feels it must be resolved. During

An open issue is no longer required for a PR, but open issues and associated PRs should have synchronized labels. For example a high priority bug issue might not have its associated PR merged if the PR is only marked as lower priority.

PR Additions

PRs are marked as targeting a milestone via the Prow "/milestone" command.

This is a blocking requirement during Code Freeze as described above.

Other Required Labels

SIG Owner Label

The SIG owner label defines the SIG to which we escalate if a milestone issue is languishing or needs additional attention. If there are no updates after escalation, the issue may be automatically removed from the milestone.

These are added with the Prow "/sig" command. For example to add the label indicating SIG Storage is responsible, comment with /sig storage.

Priority Label

Priority labels are used to determine an escalation path before moving issues out of the release milestone. They are also used to determine whether or not a release should be blocked on the resolution of the issue.

Issue/PR Kind Label

The issue kind is used to help identify the types of changes going into the release over time. This may allow the Release Team to develop a better understanding of what sorts of issues we would miss with a faster release cadence.

For release targeted issues, including pull requests, one of the following issue kind labels must be set:

  • kind/api-change: Adds, removes, or changes an API
  • kind/bug: Fixes a newly discovered bug.
  • kind/cleanup: Adding tests, refactoring, fixing old bugs.
  • kind/design: Related to design
  • kind/documentation: Adds documentation
  • kind/failing-test: CI test case is failing consistently.
  • kind/feature: New functionality.
  • kind/flake: CI test case is showing intermittent failures.

Last modified June 03, 2021 at 5:29 PM PST: