📖 Update v1.11 support matrix

[fabriziopandini]

/area documentation

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign vincepri for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mboersma]

Looks good to me, I just had some minor grammatical suggestions.

[mboersma]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: daedcf891a0454b0c0260730ac1ae920a7da6e7a

[jackfrancis]

This is not for this PR, as 1.33 support was already added for v1.10.1... but I'm curious why we aren't pinning to the same go version for 1.33 if we're introducing support for it?

Ref:

• https://github.com/kubernetes-sigs/cluster-api/blob/v1.10.1/go.mod#L3

Compare to:

• https://github.com/kubernetes/kubernetes/blob/v1.33.0/go.mod#L9

Updating to go 1.24 would obviously include updating a bunch of core libraries (apimachinery, etc), but I was under the impression that "CAPI support" for a particular version would include that affinity.

[mboersma]

why we aren't pinning to the same go version for 1.33...?

It's a good point, CAPI usually keeps those in sync.

Switching to Go 1.24 is in progress: see #12128, which may be blocked by #12088.

[fabriziopandini]

This is not for this PR, as 1.33 support was already added for v1.10.1

That's correct.
This PR is about the version that the users can use for management or workload clusters, it isn't about the version we use in our codebase.

I'm curious why we aren't pinning to the same go version for 1.33 if we're introducing support for it?

Wrt to the version we use in our codebase, the process we usually follow is described in https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-cycle.md

TL;DR; we usually use the same go version of the K8s version we are importing, which we keep in sync with the K8s version imported by the version of controller runtime we are using
(CAPI 1.10 imports CR 0.20, CR 0.20 imports K8s v1.32 which is uses go 1.23, so also CAPI does)

Additional note, the CR runtime minor bump usually happens on main only, not on release branches, so CAPI 1.10 most probably will continue to use 1.23 as go version.

[sbueringer]

A few small additions.

• CR v0.21 which would use k8s.io/* v0.33 dependencies is not released yet even as of today. Even if it would be released slightly before the CAPI release I don't want to pick up a new CR (and also k8s.io/* & Go minor version) with basically zero soak time in CI. There also is no technical reason why we have to use the same k8s.io/* versions as the highest wl cluster version we manage or the highest mgmt cluster version we run on
• If we would bump the CR / k8s.io/* / Go minor version after a .0 release this would be a breaking change to everyone importing our CAPI go module. So we don't do that
  • Note: CAPI .0 releases are usually cut before k8s.io .0. I.e. k8s.io/* v0.33.0 was not available at the time of CAPI v1.10.0

[sbueringer]

Is this correct? We just released v1.10.x and are now working on v1.11

[sbueringer]

I'm not sure if we have to update this table at all

[fabriziopandini]

@sbueringer my idea was to get this page ready for when we will release, so we do not forget (see #12124)

But happy to rollback if you prefer

[sbueringer]

I see your point. It's just that when folks look at this doc on main it's very confusing. Do we know how we did this in the past? (I would expect we have some tracking in our release tasks)

[fabriziopandini]

I would say:

Like when folks look at code in main they get the in progress implementation for the next release,
they also get in progress docs for the next release.

To your point, as far as I remember, it is our a common practice to work on the book on main documenting what will become true when we release.

We do this for every new feature, for every breaking change etc, and this already started happening also in this release: we have a page where we are documenting changes for providers, we already changed contract documentation to align to v1beta2 etc.
(e.g also in this page we are already stating v1beta2 as current APi, v1beta1 as deprecated)

[fabriziopandini]

In the release book the task is tracked as https://github.com/kubernetes-sigs/cluster-api/tree/main/docs/release/role-handbooks/communications#update-supported-versions (I guess)

[fabriziopandini]

@sbueringer, as discussed I have dropped the line for 1.12 release under development

[k8s-ci-robot]

New changes are detected. LGTM label has been removed.