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
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.
**[Code Freeze][code-freeze]** starts in week ~12 and continues for ~2 weeks.
Only critical bug fixes are accepted into the release codebase during this
time.
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:
## 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 [Release Team][release-team] may remove issues from the
milestone if they or the responsible SIG determine that the issue is not
actually blocking the release and is unlikely to be resolved in a timely
fashion.
Members of the Release Team may remove PRs from the milestone for any of the
following, or similar, reasons:
- PR is potentially de-stabilizing and is not needed to resolve a blocking
issue
- PR is a new, late feature PR and has not gone through the enhancements
process or the [exception process][exceptions]
- There is no responsible SIG willing to take ownership of the PR and resolve
any follow-up issues with it
- PR is not correctly labelled
- Work has visibly halted on the PR and delivery dates are uncertain or late
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:
- Comment in GitHub mentioning the SIG team and SIG members as appropriate for
the issue type
- Emailing the SIG mailing list
- bootstrapped with group email addresses from the