KEP-Template: Clarify the stage name of deprecated feature gates #4898
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
k8s-ci-robot
added
kind/kep
k8s-ci-robot
requested review from
jpbetz,
liggitt,
tengqm,
thockin and
wojtek-t
| @@ -22,6 +22,8 @@ replaces: | |||
| - "/keps/sig-ccc/3456-replaced-kep" | |||
|
|
|||
| # The target maturity stage in the current dev cycle for this KEP. | |||
| # If the purpose of this KEP is to deprecate a user-visible feature | |||
There was a problem hiding this comment.
This is implemented in api/proposal.go type Stage and type Milestone.
We alrady have a milestone Deprecated and another Removed. I think what we want to propose is that stage can be deprecated (meaning "deprecation was announced"), deprecated-disabled (meaning "still present but off by default and soon to be removed"), and "removed", with corresponding milestones` for each.
There was a problem hiding this comment.
Ah, you are right.
HirazawaUi
force-pushed
the
add-deprecation-stage
branch
from
8cbc810
to
c271cf2
Compare
k8s-ci-robot
added
area/enhancements
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: HirazawaUi 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
size/M
| Stable *PRRMilestone `json:"stable" yaml:"stable,omitempty"` | ||
| Deprecated *PRRMilestone `json:"deprecated" yaml:"deprecated,omitempty"` | ||
| Removed *PRRMilestone `json:"removed" yaml:"removed,omitempty"` | ||
| DeprecatedDisabled *PRRMilestone `json:"deprecatedDisabled" yaml:"deprecated-disabled,omitempty"` |
There was a problem hiding this comment.
Adding fields here is currently unused, but Removed and Deprecated fields have already been added here, and they also not be referenced by any code.
|
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
For us, deprecating a user-visible feature, or adding a bug fix that could be seen as 'removal', requires a small KEP for discussion and to document them and we also should add a Deprecated feature gate for such cases.
For these Deprecated feature gates, their lifecycle is shorter than a full feature gate lifecycle, typically following featuregate.Deprecated → wait a few releases → remove. So, we only need two phases to describe them, but we haven't clearly defined the names of these phases yet.
Some useful references: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/feature-gates.md#:~:text=Bug%20fixes%20that,can%20be%20disabled.
https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/feature-gates.md#deprecation