-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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.
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
📖 book: set v1.1.x EOL date #7146
Conversation
Signed-off-by: Stefan Büringer buringerst@vmware.com
/cherry-pick release-1.2 |
@sbueringer: once the present PR merges, I will cherry-pick it on top of release-1.2 in a new PR and assign it to you. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
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.
/lgtm
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.
/lgtm
Note that we have this policy in the doc
For each given API version only the most recent associated release branch is supported, older branches are immediately unsupported
We might want to revise it if we're not actually following it in practice
Yup. That policy was why I brought it up yesterday in the office hours. With v1.0 and (looks like now too with v1.1) we did one more patch release after the next .0 minor release. This comes roughly down to the previous minor version is supported until one month after the release of the next minor version. I'm general in favor of revising the policy. Although I wonder if dropping support at the time of the next minor release or one month later is the right thing to do. Essentially we declared ClusterAPI ready for production, but we are now 1,5 months after the v1.2 release and we don't have releases of the most frequently used infrastructure providers based on and tested with CAPI v1.2. (possibly the current infra provider releases have been tested for compatibility with v1.2, I"m not following infra providers very closely) That means basically when v1.1 will be out of support in 2 weeks, users can't use a combination of core CAPI and infra providers where both are supported. |
I agree that the implicit feedback from the provider is showing us that we are a little bit too aggressive in setting a release branch EOL even if there are no API changes on the next one. |
/lgtm Given that this is compliant with our current deprecation policy. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fabriziopandini The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@sbueringer: new pull request created: #7186 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Signed-off-by: Stefan Büringer buringerst@vmware.com
What this PR does / why we need it:
As discussed in the office hours.
I would take care of the next v1.1.x and v1.2.x release in ~ 2 weeks.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #