-
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
📖 docs: add Cluster API 1.4 and Kubernetes 1.26 to supported versions page #7696
Conversation
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.
One non-blocking comment, but this looks good - thanks for updating it.
/lgtm
| Kubernetes v1.23* | | ✓ | ✓ | ✓ | ✓ | ✓ | | ||
| Kubernetes v1.24 | | | | ✓ | ✓ | ✓ | | ||
| Kubernetes v1.25 | | | | | ✓ | ✓ | | ||
| | v0.3 (v1alpha3) | v0.4 (v1alpha4) | v1.0 (v1beta1) | v1.1 (v1beta1) | v1.2 (v1beta1) | v1.3 (v1beta1) | v1.4 (v1beta1) | |
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.
I don't think it's a blocker from this PR, but I think we should consider removing v1.0 and v1.1 from these tables. We now have two supported releases, and users can review those versions of the book if they want the correct version support for those releases.
I think v0.3 and v0.4 are different cases as they're different API versions, but we could also consider removing those in favor of keeping their compatibility information in their versions of the book.
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.
Another question: should the lowest supported Kubernetes version change? CAPI supports a lot of versions that aren't being developed.
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.
I think the CAPI support policy has been to assume that version of Kubernetes works up until there's a signal that it doesn't, or an actual breaking change.
There's still tests being run against these older versions of K8s too - so the community would have to make an affirmative decision to stop supporting some of these older versions IMO - possibly a good question for a community meeting.
There's also a couple of related issues open to enforce this in webhooks (at least for KCP) e.g. #7010. Today we don't enforce the versions of Kubernetes at all, so that would definitely be a start IMO, but it would create a situation where choosing to not support a version becomes explicit and strict i.e. someone has to make a PR that will block Kubernetes 1.16 in KCP.
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.
I will bring up discussions next year in January to discuss a few of our support policies where this will be included.
/lgtm
That's one of the "tech debts" points I would like to bring up at office hours... we should find a way to ensure this matrix does not grow indefinitely especially now that we back supporting one more branch (and probably we also need another one to align with -2 policy which is kind of standard in the ecosystem) |
[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 |
What this PR does / why we need it:
Adds Cluster API 1.4 and Kubernetes 1.26 (released 8DEC) to the supported versions page.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Partof #7672