kubebuilder
kubebuilder copied to clipboard
Define and doc an standard for the PR titles to make clear specific plugins changes
What do you want to happen?
IMO: We need to discuss in the community meeting what standard we would like to have to make clear in the release notes that the changes made are valid only for some specific plugin (to be easier for users to have this information by looking at the release notes). Then, we need to doc it out in: https://github.com/kubernetes-sigs/kubebuilder/blob/master/CONTRIBUTING.md (to make clear for contributes how that need to be done, when and why)
See the release notes: https://github.com/kubernetes-sigs/kubebuilder/releases
Some options/suggestions:
-
<icon indicating whether it's a> ( plugin/version ) : <description>
-
<icon indicating whether it's a> For plugin/version, : <description>
See how we do it in the templates to generate the release notes in SDK:
https://github.com/operator-framework/operator-sdk/blob/master/changelog/fragments/00-template.yaml#L10-L14
Extra Labels
No response
May I suggest the 🔌 :electric_plug:
Icon? Seems fitting 😄
The icons are used to define bug fixes, breaking changes and etc:
Every PR should be annotated with an icon indicating whether it's a:
- Breaking change: :warning: (
:warning:
) - Non-breaking feature: :sparkles: (
:sparkles:
) - Patch fix: :bug: (
:bug:
) - Docs: :book: (
:book:
) - Infra/Tests/Other: :seedling: (
:seedling:
) - No release note: :ghost: (
:ghost:
)
Then, it will be used to. break the subsections in the release notes. ( https://github.com/kubernetes-sigs/kubebuilder/releases)
Not sure how the :electric_plug: Icon would fit in this case.
Oh, maybe I missunderstood your request, I thought you wanted to have a new one for PRs related to plugins? My bad if that was not the case
Teh goal is to define a standard for the releases notes which are Breaking changes, Patch fix, etc but that does affect the specific plugin and not all. See the examples in the release notes with (go/v2 or go/v3) for example: https://github.com/kubernetes-sigs/kubebuilder/releases
Hey @camilamacedo86 🙂 I can work on this if this issue is not assigned to anyone.
HI @Ankit152,
We will need first to check with the Community what the standard should be and what they think about it. Then, we can move forward. I am hoping we have this conversation in the next KB / C+R meeting : https://docs.google.com/document/d/1Ih-2cgg1bUrLwLVTB9tADlPcVdgnuMNBGbUl4D-0TIk/edit#heading=h.dp4gt7gj3cn
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/stale
is applied - After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied - After 30d of inactivity since
lifecycle/rotten
was applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale
- Mark this issue or PR as rotten with
/lifecycle rotten
- Close this issue or PR with
/close
- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
Done, It is added in the contribution guide now.