Skip to content

Document versioning plan and upgrade recommendations #1347

@robscott

Description

@robscott

As we're thinking about the long term use of CRDs for this API, we'll want to ensure that both users and implementations have a smooth experience across CRD upgrades.

Here's a high level starting point based on discussions with folks from sig-apimachinery around the proper way to handle stored and served versions.

Minor release 1 (v0.5.0 for these resources):

  • Release new API version (v1beta1)
  • Leave old version as storage version (v1alpha2)
  • Serve both API versions to simplify migration

Minor release 2 (v0.6.0 for these resources):

  • Set new version as storage version (v1beta1)
  • Stop serving old API version (v1alpha2)
  • Recommend users run a tool such as kube-storage-version-migrator in their clusters if they have resources that were created with the alpha API

Minor release 3 or later (v0.7.0 for these resources):

  • Remove old API version from the API

/assign

Metadata

Metadata

Assignees

Labels

kind/documentationCategorizes issue or PR as related to documentation.lifecycle/rottenDenotes an issue or PR that has aged beyond stale and will be auto-closed.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions