Skip to content

Remove v1beta1 apiVersion #11920

Open
Open
@sbueringer

Description

@sbueringer

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

Metadata

Metadata

Assignees

Labels

kind/cleanupCategorizes issue or PR as related to cleaning up code, process, or technical debt.lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.priority/backlogHigher priority than priority/awaiting-more-evidence.triage/acceptedIndicates an issue or PR is ready to be actively worked on.

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions