Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
.Uh oh!
There was an error while loading. Please reload this page.
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
labels when a release note is added...because that is a user facing deprecationThere 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...)
release note required
out of this document, instead it should be part of the release notes document linked abovekind/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).