-
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
📖 Add v1alpha4 to v1beta1 upgrade doc #5264
📖 Add v1alpha4 to v1beta1 upgrade doc #5264
Conversation
270ac9a
to
2572b1b
Compare
18c62cc
to
bfdace7
Compare
bfdace7
to
f852d1a
Compare
f852d1a
to
154f105
Compare
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
Is this type of change to the contract a worthwhile inclusion: #4949 ? |
This is already included in v1alpha4, so no need to document in the v1alpha4 --> v1beta1 doc; however, generally speaking,contract changes should be documented in this doc. |
Is it worth adding a comment about potentially supporting conversions from v1alpha3 as well as v1alpha4 to the storage version? |
So should that change be included in the v1alpha3 -> v1alpha4 docs? |
This change was introduced during v1alpha4, not from v1alpha3->v1alpha4. I don't think that providers will re-read the v1alpha3=>v1alpha4 migration doc once they migrated to v1alpha4.
I think that makes sense, if the idea is that infra providers also potentially support the migration from v1alpha3=>v1beta1. I added a section about it, I assume it's optional for providers to support it. |
Signed-off-by: Stefan Büringer [email protected]
154f105
to
b9a8de8
Compare
/lgtm Let document retroactively #4949 on v1alpha3 -> v1alpha4 doc + the need of implementing InfrastructureClusterTemplate or ControlPlaneTemplate for ClusterClass support |
[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:
This PR adds the initial version of the upgrade doc.
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 #5262