kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update Release Notes Document to reflect PR boilerplate changes

This commit is contained in:
onyiny-ang 2020-06-11 20:44:22 -04:00
parent 6afa05a9bb
commit 2fd4334796
No known key found for this signature in database
GPG Key ID: 156A6435430C2036
1 changed files with 30 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
contributors/guide/release-notes.md
View File

@ -5,8 +5,17 @@ slug: "release-notes"
---
On the kubernetes/kubernetes repository, release notes are required for any pull
request with user-visible changes, such as bug fixes, feature additions, and
output format changes. Release notes are one of the most important reference
request with user-visible changes, this could mean:
##### - User facing, critical bug-fixes
##### - Notable feature additions
##### - Output format changes
##### - Deprecations or removals
##### - Metrics changes
##### - Dependency changes
##### - API changes
Release notes are one of the most important reference
points for users about to install or upgrade to a particular release of
Kubernetes.
@ -45,6 +54,10 @@ A release note needs a clear, concise description of the change. This includes:
4. a link to relevant user documentation about the enhancement/feature
## Applying a Release Note
slug: "adding-release-notes"
On the kubernetes/kubernetes repository, release notes are required for any pull request with [user-visible changes](#--user-facing-critical-bug-fixes).
To meet this requirement, do one of the following:
- Add notes in the release notes block, or
@ -72,7 +85,21 @@ For pull requests that don't need to be mentioned at release time, use the `/rel
NONE
```
To see how to format your release notes, view the kubernetes/kubernetes [pull request template](https://git.k8s.io/kubernetes/.github/PULL_REQUEST_TEMPLATE.md) for a brief example. Pull Request titles and body comments can be modified at any time prior to the release to make them friendly for release notes.
Your release note should be written in clear and straightforward sentences. Most often, users aren't familiar with the technical details of your PR, so consider what they _need to know_ when you write your release note.
Some brief examples of release notes:
```
The deprecated flag --conntrack-max has been removed from kube-proxy. Users of this flag should switch to --conntrack-min and --conntrack-max-per-core instead. (#78399, @rikatz)
The --export flag for the kubectl get command, deprecated since v1.14, will be removed in v1.18.
Fixed a bug that prevents dry-run from being honored for the pod/eviction sub-resource. (#76969, @apelisse)
```
Pull Request titles and body comments can be modified at any time prior to the release to make them friendly for release notes.
The release notes team maintains a [template](https://github.com/kubernetes/sig-release/blob/master/release-team/role-handbooks/release-notes/relnotes-template.md) for Kubernetes Release notes that may help clarify whether or not your PR requires a release note. The most recent [Kubernetes Release notes](https://kubernetes.io/docs/setup/release/notes/) can also provide insight into the writing style for release notes.
Release notes apply to pull requests on the master branch. For patch release branches the automated cherry-pick pull requests process (see the [cherry-pick instructions](/contributors/devel/sig-release/cherry-picks.md)) should be followed. That automation will pull release notes from the master branch PR from which the cherry-pick originated. On a rare occasion a pull request on a patch release branch is not a cherry-pick, but rather is targeted directly to the non-master branch and in this case, a `release-note-*` label is required for that non-master pull request.