Support policy for new minor versions on older major versions#423
Support policy for new minor versions on older major versions#423k8s-ci-robot merged 1 commit intokubernetes-csi:masterfrom chrishenzie:minor-version-support
Conversation
k8s-ci-robot
added
the
do-not-merge/release-note-label-needed
k8s-ci-robot
added
size/XS
k8s-ci-robot
added
release-note-none
| To minimize the number of branches we need to support, we do not have a general | ||
| policy for releasing new minor versions on older majors. We will make exceptions | ||
| for work related to meeting production readiness requirements. | ||
|
|
There was a problem hiding this comment.
We should add a clause that this older major can only be one version lower than the current major and also the time between the two major releases is less than 3-4 months, etc.
There was a problem hiding this comment.
Done. Does the wording above make sense?
There was a problem hiding this comment.
i'm not sure how to read this. Are we trying to say that if "X.0.0" and "X+1.0.0" were released about a quarter apart, then we will consider some exception?
But if it was "X.2.0" and "X+1.0.0", then we won't consider any exception?
There was a problem hiding this comment.
Something like that. We only look at the initial release times of the major releases for minor release exceptions. Otherwise we could end up with too many releases. For example, if X.0.0 was released a year before X+1.0.0, we should move on and not to keep releasing minor releases on X.
There was a problem hiding this comment.
Does the wording in this PR capture this in an understandable way? Or what if we worded it like so?
Only prior major versions released within four months of the current major version will be eligible for this exception.
This wording does broaden it to more than one major release, but maybe that's more intuitive than the current wording.
There was a problem hiding this comment.
I think the wording as is captures it, but I wanted to confirm the intended scenario. Maybe give an example with numbers to make it more clear.
There was a problem hiding this comment.
Just checking if this captures everything. Do we also want to add a section for RBAC not requiring new majors?
There was a problem hiding this comment.
I think RBACs still require some more discussion, so let's consider that separately.
book/src/project-policies.md
Outdated
| policy for releasing new minor versions on older majors. We will make exceptions | ||
| for work related to meeting production readiness requirements. Only the previous | ||
| major version will be eligible for these exceptions, so long as the time between | ||
| the previous major version and the current major version is under four months. |
There was a problem hiding this comment.
Thinking about this some more, given that the Kubernetes release cadence is slowling down, I wonder if 4 months is actually enough enough to capture even a single release. Should we bump it to 6 months? @xing-yang
| To minimize the number of branches we need to support, we do not have a general | ||
| policy for releasing new minor versions on older majors. We will make exceptions | ||
| for work related to meeting production readiness requirements. | ||
|
|
There was a problem hiding this comment.
I think RBACs still require some more discussion, so let's consider that separately.
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: chrishenzie, msau42 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
4 participants
See #419 for more context.
Any assistance with clarifying the wording is appreciated.
Does this PR introduce a user-facing change?