Features or enhancements are effectively GitHub issues or [KEPs][keps] which
lead to subsequent PRs.
The general labeling process should be consistent across artifact types.
## Definitions
- *issue owners*: Creator, assignees, and user who moved the issue into a
release milestone
- *Release Team*: Each Kubernetes release has a team doing project management
tasks described [here][release-team].
The contact info for the team associated with any given release can be found
[here](https://git.k8s.io/sig-release/releases/).
- *Y days*: Refers to business days
- *enhancement*: see "[Is My Thing an Enhancement?](https://git.k8s.io/enhancements/README.md#is-my-thing-an-enhancement)"
- *[Enhancements Freeze][enhancements-freeze]*:
the deadline by which [KEPs][keps] have to be completed in order for
enhancements to be part of the current release
- *[Exception Request][exceptions]*:
The process of requesting an extension on the deadline for a particular
Enhancement
- *[Code Freeze][code-freeze]*:
The period of ~4 weeks before the final release date, during which only
critical bug fixes are merged into the release.
- *[Pruning](https://git.k8s.io/sig-release/releases/release_phases.md#pruning)*:
The process of removing an Enhancement from a release milestone if it is not
fully implemented or is otherwise considered not stable.
- *release milestone*: semantic version string or
[GitHub milestone](https://help.github.com/en/github/managing-your-work-on-github/associating-milestones-with-issues-and-pull-requests)
referring to a release MAJOR.MINOR `vX.Y` version.
See also
[release versioning](https://git.k8s.io/sig-release/release-engineering/versioning.md).
- *release branch*: Git branch `release-X.Y` created for the `vX.Y` milestone.
Created at the time of the `vX.Y-rc.0` release and maintained after the
release for approximately 12 months with `vX.Y.Z` patch releases.
Note: releases 1.19 and newer receive 1 year of patch release support, and
releases 1.18 and earlier received 9 months of patch release support.
## The Release Cycle
Kubernetes releases currently happen approximately three 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. **[Enhancements Freeze][enhancements-freeze]**
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 [Enhancements Lead](https://git.k8s.io/sig-release/release-team/role-handbooks/enhancements/README.md).
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 [Release Team][release-team] can track bugs and enhancements (any
enhancement-related issue needs a milestone).
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