-
Notifications
You must be signed in to change notification settings - Fork 5.2k
release: document kind/deprecation #7600
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
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]>
[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 |
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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/*deprecation
labels when a release note is added...because that is a user facing deprecation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, that's my take.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey folks 👋
I want to check first, what's the status of this PR? Do you need any help from SIG Release to move it forward?
My 2 cents are (tl;dr) that I in large agree with @neolit123 here:
kind/deprecation
should not be used only for APIs, instead it should be about anything user-facing. I'd rather phrase this asdeprecates a user facing feature (e.g. API, command...)
- I'd keep
release note required
out of this document, instead it should be part of the release notes document linked above - I also agree about not requiring the release note for deprecations, but with a little conflict. I would prefer (at least in some of mentioned cases) using
kind/cleanup
if we're talking about non-user facing things. For example: tests, documentation for maintainers; I think all of that is kind of covered bykind/cleanup
already, or it can be more-or-less easily extended to cover that.
To add on this, I think there's a couple of things that we lack in the process. For example, kind/deprecation
is used for removals at the moment and I find this wrong. Deprecation is more like announcing intention to stop supporting something followed by its removal, or just announcing its removal. Ideally, I think we should consider adding some additional labels, but we would have to involve all stakeholders before changing this (different SIGs, Leads, and the Release Team).
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 |
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 |
/remove-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 |
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 |
/remove-lifecycle rotten |
Assigning our subproject leads for review: |
/uncc @justaugustus @jeremyrickard |
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 |
/remove-lifecycle rotten |
/remove-lifecycle stale |
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 |
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 |
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 #