Open
Description
Tracking issue for v1beta1 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.
v1beta1
CAPI | Release date | v1beta1 | v1beta2 | Notes |
---|---|---|---|---|
v1.9 | Dec 24 | Served: true, Storage | ||
v1.10 | April 25 | Served: true, Storage | ||
v1.11 | August 25 | Served: true | Served: true, Storage | v1beta2 added |
v1.12 | December 25 | Served: true | Served: true, Storage | |
v1.13 | April 26 | Served: true | Served: true, Storage | |
v1.14 | August 26 | Served: false | Served: true, Storage | v1beta1 unserved |
v1.15 | December 26 | Served: false | Served: true, Storage | |
v1.16 | April 27 | Served: false | Served: true, Storage | |
v1.17 | August 27 | Served: false | Served: true, Storage | |
v1.18 | December 27 | Served: true, Storage | v1beta1 removed |
Notes:
- v1.11-v1.13: We have to keep v1beta1 served for 3 versions after introduction of v1beta2 according to the Kubernetes deprecation policy
- v1.14-v1.17: We have to keep v1beta1 around for 3 versions after it was unserved, to ensure that managedField cleanup is run even if someone upgrades from n-3 => n.
- Note: We want to keep v1beta1 around for one additional release so that folks have 1 buffer release where they can revert v1beta1 back to served if they need more time to pick up v1beta2 (we did the same for v1alpha3 + v1alpha4 in the past).
Tasks:
- [v1.11] Introduce v1beta2 (tracked elsewhere)
- [v1.14] Unserve & deprecate v1beta1
- [v1.18] Remove v1beta1
For more context, see: #11894