Merge pull request #10531 from fabriziopandini/add-EOL-statements

📖 A few version bump in the docs

Author: k8s-ci-robot

CONTRIBUTING.md

@@ -161,7 +161,7 @@ Cluster API maintains the most recent release/releases for all supported API and
 - For the current stable API version (v1beta1) we support the two most recent minor releases; older minor releases are immediately unsupported when a new major/minor release is available.
 - For older API versions we only support the most recent minor release until the API version reaches EOL.
 - We will maintain test coverage for all supported minor releases and for one additional release for the current stable API version in case we have to do an emergency patch release.
-  For example, if v1.2 and v1.3 are currently supported, we will also maintain test coverage for v1.1 for one additional release cycle. When v1.4 is released, tests for v1.1 will be removed.
+  For example, if v1.6 and v1.7 are currently supported, we will also maintain test coverage for v1.5 for one additional release cycle. When v1.8 is released, tests for v1.5 will be removed.
 
 | Minor Release | API Version  | Supported Until                                |
 |---------------|--------------|------------------------------------------------|
@@ -183,9 +183,9 @@ Cluster API maintains the most recent release/releases for all supported API and
 
 ### Removal of v1alpha3 & v1alpha4 apiVersions
 
-Both v1alpha3 and v1alpha4 have been removed from Cluster API as of release 1.7.
-
-For more details and latest information please see the following issue: [Removing v1alpha3 & v1alpha4 apiVersions](https://github.com/kubernetes-sigs/cluster-api/issues/8038).
+Cluster API stopped to serve v1alpha3 API types from the v1.5 release and v1alpha4 types starting from the v1.6 release.
+Those types still exist in Cluster API while we work to a fix (or a workaround) for https://github.com/kubernetes-sigs/cluster-api/issues/10051.
+IMPORTANT! v1alpha3 and v1alpha4 types only exist for conversion and cannot be used by clients anymore.
 
 Note: Removal of a deprecated APIVersion in Kubernetes [can cause issues with garbage collection by the kube-controller-manager](https://github.com/kubernetes/kubernetes/issues/102641)
 This means that some objects which rely on garbage collection for cleanup - e.g. MachineSets and their descendent objects, like Machines and InfrastructureMachines, may not be cleaned up properly if those

docs/book/src/clusterctl/commands/upgrade.md

@@ -83,13 +83,13 @@ Cluster API only tests a subset of possible clusterctl upgrade paths as otherwis
 Untested upgrade paths are not blocked by clusterctl and should work in general, they are just not tested. Users
 intending to use an upgrade path not tested by us should do their own validation to ensure the operation works correctly.
 
-The following is an example of the tested upgrade paths for v1.5:
+The following is an example of the tested upgrade paths for v1.7:
 
 | From | To   | Note                                                 |
 |------|------|------------------------------------------------------|
-| v1.0 | v1.5 | v1.0 is the first release with the v1beta1 contract. |
-| v1.3 | v1.5 | v1.3 is v1.5 - 2.                                    |
-| v1.4 | v1.5 | v1.4 is v1.5 - 1.                                    |
+| v1.0 | v1.7 | v1.0 is the first release with the v1beta1 contract. |
+| v1.5 | v1.7 | v1.5 is v1.7 - 2.                                    |
+| v1.6 | v1.7 | v1.6 is v1.7 - 1.                                    |
 
 The idea is to always test upgrade from v1.0 and the previous two minor releases.
 

docs/book/src/reference/versions.md

@@ -23,10 +23,10 @@ When a new Kubernetes minor release is available, we will try to support it in a
 (although only in the latest supported Cluster API minor release). See Cluster API [release cycle](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-cycle.md)
 and [release calendars](https://github.com/kubernetes-sigs/cluster-api/tree/main/docs/release/releases) for more details.
 
-For example, Cluster API v1.5.0 would support the following Kubernetes versions:
-* v1.24.x to v1.27.x for the management cluster
-* v1.22.x to v1.27.x for the workload cluster
-* When Kubernetes 1.28 is released, it will be supported in v1.5.x (but not in v1.4.x)
+For example, Cluster API v1.7.0 would support the following Kubernetes versions:
+* v1.26.x to v1.29.x for the management cluster
+* v1.24.x to v1.29.x for the workload cluster
+* When Kubernetes 1.30 is released, it will be supported in v1.7.x (but not in v1.6.x)
 
 Support in this context means that we:
 * maintain corresponding code paths
@@ -57,8 +57,8 @@ The Core Provider, Kubeadm Bootstrap Provider, and Kubeadm Control Plane Provide
 In some cases, the Management Cluster is separate from the Workload Clusters. The Kubernetes version of the Management and Workload Clusters are allowed to be different.
 
 Management Clusters and Workload Clusters can be upgraded independently and in any order, however, if you are additionally moving from
-v1alpha3 (v0.3.x) to v1beta1 (v1.x) as part of the upgrade rollout, the management cluster will need to be upgraded to at least v1.20.x,
-prior to upgrading any workload cluster using Cluster API v1beta1 (v1.x)
+v1alpha3 (v0.3.x) or v1alpha4 (v0.4.x) to v1beta1 (v1.x) as part of the upgrade, prior to upgrading any workload cluster using Cluster API v1beta1, 
+the management cluster will need to be upgraded the at least the minimum supported Kubernetes version for your target CAPI version.
 
 These diagrams show the relationships between components in a Cluster API release (yellow), and other components (white).
 

docs/release/release-cycle.md

@@ -1,6 +1,6 @@
 # Release Cycle
 
-The release cycle is the time between when we start working on a release on the `main` branch until the `.0` release (e.g. `v1.3.0`) is released.
+The release cycle is the time between when we start working on a release on the `main` branch until the `.0` release (e.g. `vX.Y.0`) is released.
 
 Each release cycle will last approximately 4 months (~ 17 weeks) and it can be split up into the following phases:
 

docs/release/release-tasks.md

@@ -122,6 +122,7 @@ Prior art:
 
 * 1.5 - https://github.com/kubernetes-sigs/cluster-api/pull/8430/files
 * 1.6 - https://github.com/kubernetes-sigs/cluster-api/pull/9097/files
+* 1.7 - https://github.com/kubernetes-sigs/cluster-api/pull/9799/files
 
 #### Create a new GitHub milestone for the next release