release: document kind/deprecation #7600
Conversation
This appears in the PR templates but isn't documented. Since it enforces release notes, it's presumably intended for PRs deprecating APIs rather than for PRs fixing deprecated usage. Signed-off-by: Stephen Kitt <[email protected]>
k8s-ci-robot
added
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: skitt The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
area/developer-guide
| @@ -337,6 +337,7 @@ 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/deprecation`: Deprecates an API (release notes required). | |||
There was a problem hiding this comment.
One thing that comes up from time to time is whether release notes need to be added for Go API changes - this is particularly relevant for deprecations of Go APIs when this kind is used: kubernetes/kubernetes#120567 (comment)
Perhaps we can use PR to also elaborate on that aspect?
My own take: I add release notes for Go API changes when they seem significant enough, but not for everything.
There was a problem hiding this comment.
Given the general terseness of this document, wouldn’t that be better in https://github.com/kubernetes/community/blob/master/contributors/guide/release-notes.md?
There was a problem hiding this comment.
Yes. Could still be in this PR, though, because it is related as seen when @neolit123 tried to use kind/deprecation.
There was a problem hiding this comment.
my feedback:
- kind deprecation should not require a release-note. it seems like a guard rail for lack of release notes; release notes should be in place regardless. if maintainers are not asking for them, then we have a wider problem.
- reading into the label without context, kind deprecation is about anything that is being deprecated; examples: a document, a test, some code that only maintainers care about, an API. so not only about APIs.
- if we want a specialized label for APIs it can be kind api-deprecation
- the release notes team should only process
kind/*deprecationlabels when a release note is added...because that is a user facing deprecation
There was a problem hiding this comment.
@neolit123 I take it you’re saying we should fix the process, and document the fixed process, rather than document a flawed process; is that correct? (Assuming enough stakeholders agree that the process is flawed.)
|
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
k8s-ci-robot
added
lifecycle/rotten
|
/remove-lifecycle rotten |
k8s-ci-robot
removed
the
lifecycle/rotten
|
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
This appears in the PR templates but isn't documented. Since it enforces release notes, it's presumably intended for PRs deprecating APIs rather than for PRs fixing deprecated usage.
Which issue(s) this PR fixes:
Fixes #