Remove v1alpha3 + v1alpha4 apiVersions #11919
Description
Tracking issue for v1alpha3 + v1alpha4 apiVersion removal. This will stay around for a while.
Context:
- CAPI supports 3 versions: for 2 versions we regularly release patch releases, for the 3rd one we create emergency patches on demand
- CAPI currently tests up to n-3 => n upgrades.
- Note: This is not well documented at the moment, but we should follow-up.
- Note: The n-3 => n policy in CAPI aligns to the corresponding policy in Kubernetes
- We want to make sure that removal of old apiVersions do not break the n-3 => n upgrade path. This means that we have to keep apiVersions around long enough that "storage version migration" and "managedField cleanup" are run.
v1alpha3 & v1alpha4
| CAPI | Release date | v1alpha3 + v1alpha4 | Notes |
|---|---|---|---|
| v1.9 | Dec 2024 | Served: false | |
| v1.10 | April 2025 | Served: false | CRD migrator added |
| v1.11 | August 2025 | Served: false | |
| v1.12 | December 2025 | Served: false | |
| v1.13 | April 2026 | v1alpha3 + v1alpha4 removed | |
| v1.14 | August 2026 | ||
| v1.15 | December 2026 |
Notes:
- v1.10-v1.12: We have to keep v1alpha3 + v1alpha4 around for 3 versions after the CRD migrator has been added, to ensure that managedField cleanup is run even if someone upgrades from n-3 => n
Tasks:
- [v1.13] Remove v1alpha3 + v1alpha4
For more context, see: #11894