Skip to content

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.

Sign up for GitHub

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

Closed
wants to merge 1 commit into from
Closed

release: document kind/deprecation #7600

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions contributors/devel/sig-release/release.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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).
Copy link
Contributor

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.

Copy link
Member Author

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?

Copy link
Contributor

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.

Copy link
Member

@neolit123 neolit123 Nov 9, 2023 •
edited
Loading

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

Copy link
Member Author

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.)

Copy link
Member

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.

Copy link
Member

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 as deprecates 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 by kind/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).

- `kind/design`: Related to design
- `kind/documentation`: Adds documentation
- `kind/failing-test`: CI test case is failing consistently.
Expand Down