<commit_before># Targeting Features, Issues and PRs to Release Milestones

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

-   [TL;DR](#tldr)
-   [Definitions](#definitions)
-   [The Release Cycle](#the-release-cycle)
-   [Removal Of Items From The Milestone](#removal-of-items-from-the-milestone)
-   [Adding An Item To The Milestone](#adding-an-item-to-the-milestone)
    -   [Milestone Maintainers](#milestone-maintainers)
    -   [Feature additions](#feature-additions)
    -   [Issue additions](#issue-additions)
    -   [PR Additions](#pr-additions)
-   [Other Required Labels](#other-required-labels)
    -   [SIG Owner Label](#sig-owner-label)
    -   [Priority Label](#priority-label)
    -   [Issue Kind Label](#issue-kind-label)

The process for shepherding features, issues, and pull requests
into a Kubernetes release spans multiple stakeholders:
* the feature, issue, or pull request owner
* SIG leadership
* the release team

Information on workflows and interactions are described below.

As the owner of a feature, 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](cherry-picks.md) 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:
<table>
<tr>
<td></td>
<td>Normal Dev</td>
<td>Code Freeze</td>
<td>Post-Release</td>
</tr>
<tr>
<td></td>
<td>Weeks 1-8</td>
<td>Weeks 9-11</td>
<td>Weeks 11+</td>
</tr>
<tr>
<td>Required Labels</td>
<td>
<ul>
<!--Weeks 1-8-->
<li>/sig {name}</li>
<li>/kind {type}</li>
<li>/lgtm</li>
<li>/approved</li>
</ul>
</td>
<td>
<ul>
<!--Weeks 9-11-->
<li>/milestone {v1.y}</li>
<li>/sig {name}</li>
<li>/kind {bug, failing-test}</li>
<li>/lgtm</li>
<li>/approved</li>
</ul>
</td>
<td>
<!--Weeks 11+-->
Return to 'Normal Dev' phase requirements:
<ul>
<li>/sig {name}</li>
<li>/kind {type}</li>
<li>/lgtm</li>
<li>/approved</li>
</ul>

Merges into the 1.y branch are now [via cherrypicks](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md), approved by release branch manager.
</td>
<td>
<ul>
</td>
</tr>
</table>

In the past there was a requirement for a milestone targeted pull
request to have an associated GitHub issue opened, but this is no
longer the case.  Features are effectively GitHub issues or
[KEPs](https://git.k8s.io/community/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](https://git.k8s.io/sig-release/release-team/README.md).  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 (using the location local to the release-manager M-F).
- *feature*: see "[Is My Thing a Feature?](http://git.k8s.io/features/README.md#is-my-thing-a-feature)
- *release milestone*: semantic version string or [GitHub milestone](https://help.github.com/articles/associating-milestones-with-issues-and-pull-requests/) referring to a release MAJOR.MINOR vX.Y version.  See also [release versioning](http://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
- *release branch*: Git branch "release-X.Y" created for the vX.Y milestone.  Created at the time of the vX.Y-beta.0 release and maintained after the release for approximately 9 months with vX.Y.Z patch releases.

## The Release Cycle

![Image of one Kubernetes release cycle](release-cycle.png)

Kubernetes releases currently happen four times per year.  The release
process can be thought of as having three main phases:
* Feature 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.  The **enhancement 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 enhancement freeze, applying milestones to PRs and Issues is
important. Items within the milestone are used as a punchdown list to
complete the release. Milestones **must** be applied correctly and managed
aggressively to properly gauge what will go into a release and what
effort may be needed and when.

What would qualify to go into a current milestone? Any item that is
required for, or slated to go into, the current release. These could
be issues or PRs in repos including (but not limited to):

- kubernetes/enhancements
- kubernetes/kubernetes
- kubernetes/release
- kubernetes/sig-release
- kubernetes/website

Implementation and bugfixing is ongoing across the cycle, but<commit_msg>update language from guin's suggestion<commit_after># Targeting Features, Issues and PRs to Release Milestones

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

-   [TL;DR](#tldr)
-   [Definitions](#definitions)
-   [The Release Cycle](#the-release-cycle)
-   [Removal Of Items From The Milestone](#removal-of-items-from-the-milestone)
-   [Adding An Item To The Milestone](#adding-an-item-to-the-milestone)
    -   [Milestone Maintainers](#milestone-maintainers)
    -   [Feature additions](#feature-additions)
    -   [Issue additions](#issue-additions)
    -   [PR Additions](#pr-additions)
-   [Other Required Labels](#other-required-labels)
    -   [SIG Owner Label](#sig-owner-label)
    -   [Priority Label](#priority-label)
    -   [Issue Kind Label](#issue-kind-label)

The process for shepherding features, issues, and pull requests
into a Kubernetes release spans multiple stakeholders:
* the feature, issue, or pull request owner
* SIG leadership
* the release team

Information on workflows and interactions are described below.

As the owner of a feature, 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](cherry-picks.md) 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:
<table>
<tr>
<td></td>
<td>Normal Dev</td>
<td>Code Freeze</td>
<td>Post-Release</td>
</tr>
<tr>
<td></td>
<td>Weeks 1-8</td>
<td>Weeks 9-11</td>
<td>Weeks 11+</td>
</tr>
<tr>
<td>Required Labels</td>
<td>
<ul>
<!--Weeks 1-8-->
<li>/sig {name}</li>
<li>/kind {type}</li>
<li>/lgtm</li>
<li>/approved</li>
</ul>
</td>
<td>
<ul>
<!--Weeks 9-11-->
<li>/milestone {v1.y}</li>
<li>/sig {name}</li>
<li>/kind {bug, failing-test}</li>
<li>/lgtm</li>
<li>/approved</li>
</ul>
</td>
<td>
<!--Weeks 11+-->
Return to 'Normal Dev' phase requirements:
<ul>
<li>/sig {name}</li>
<li>/kind {type}</li>
<li>/lgtm</li>
<li>/approved</li>
</ul>

Merges into the 1.y branch are now [via cherrypicks](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md), approved by release branch manager.
</td>
<td>
<ul>
</td>
</tr>
</table>

In the past there was a requirement for a milestone targeted pull
request to have an associated GitHub issue opened, but this is no
longer the case.  Features are effectively GitHub issues or
[KEPs](https://git.k8s.io/community/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](https://git.k8s.io/sig-release/release-team/README.md).  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 (using the location local to the release-manager M-F).
- *feature*: see "[Is My Thing a Feature?](http://git.k8s.io/features/README.md#is-my-thing-a-feature)
- *release milestone*: semantic version string or [GitHub milestone](https://help.github.com/articles/associating-milestones-with-issues-and-pull-requests/) referring to a release MAJOR.MINOR vX.Y version.  See also [release versioning](http://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
- *release branch*: Git branch "release-X.Y" created for the vX.Y milestone.  Created at the time of the vX.Y-beta.0 release and maintained after the release for approximately 9 months with vX.Y.Z patch releases.

## The Release Cycle

![Image of one Kubernetes release cycle](release-cycle.png)

Kubernetes releases currently happen four times per year.  The release
process can be thought of as having three main phases:
* Feature 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.  The **enhancement 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 enhancement 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 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 only applies to the following repos:

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

**On PRs against the master branch**, milestones are auto-applied so
this is less necessary. 

**On PRS against anything not master** the milestone
requirement is absolute and iron-clad 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.

*"Milestone early and milestone often. Everyone will be happier."*

Implementation and bugfixing is ongoing across the cycle, but
{'fraction_non_alphanumeric': 0.1031275720164609, 'fraction_numerical': 0.00411522633744856, 'mean_word_length': 4.463579136690647, 'pattern_counts': {'":': 0, '<': 143, '<?xml version=': 0, '>': 143, 'https://': 12, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7308043', 'n_tokens_mistral': 3681, 'n_tokens_neox': 3467, 'n_words': 1461}