Pre-flight checks
Problem / Use case
Looking forward to GA release, the project needs to determine both how we communicate the Kubernetes and Valkey versions in the operator as well as how we intend to support older versions.
Proposed solution
Based on discussions in the weekly operator/helm meeting, I propose the following:
Versioning
Only one major version is supported at any given time. Minor versions in the major version line will get patches as needed. Previous major versions will not be patched. Any major versions below the current major version number will be considered EOL immediately upon release of the next major.
Communication
At the time of release, the operator project will provide a support matrix that in includes both Valkey and Kubernetes versions.
The first non-heading row will include the most recent version and go in reverse version order to the oldest.
On the horizontal axis it will include Y/N columns indicating operator EOL and support for Valkey or k8s minor/major versions.
Both Valkey and K8s do not rapidly release minor versions so this chart may grow horizontally, but at a reasonable rate. Only one previous major version will be included on the chart - everything else will be considered historical and will be dropped off the chart. This will contain any horizontal growth.
Here is a mockup (using Google Sheets) but it will be rendered via tables in Markdown and/or the Valkey.io docs/website.
Scope of change
Small (small CRD field or controller behaviour tweak)
API / behaviour impact
Contribution
Additional context
No response
Pre-flight checks
Problem / Use case
Looking forward to GA release, the project needs to determine both how we communicate the Kubernetes and Valkey versions in the operator as well as how we intend to support older versions.
Proposed solution
Based on discussions in the weekly operator/helm meeting, I propose the following:
Versioning
Only one major version is supported at any given time. Minor versions in the major version line will get patches as needed. Previous major versions will not be patched. Any major versions below the current major version number will be considered EOL immediately upon release of the next major.
Communication
At the time of release, the operator project will provide a support matrix that in includes both Valkey and Kubernetes versions.
The first non-heading row will include the most recent version and go in reverse version order to the oldest.
On the horizontal axis it will include Y/N columns indicating operator EOL and support for Valkey or k8s minor/major versions.
Both Valkey and K8s do not rapidly release minor versions so this chart may grow horizontally, but at a reasonable rate. Only one previous major version will be included on the chart - everything else will be considered historical and will be dropped off the chart. This will contain any horizontal growth.
Here is a mockup (using Google Sheets) but it will be rendered via tables in Markdown and/or the Valkey.io docs/website.
Scope of change
Small (small CRD field or controller behaviour tweak)
API / behaviour impact
v1alpha1.Contribution
Additional context
No response