-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
005: Add proposal for SpinKube releases #14
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Kate Goldenring <[email protected]>
|
||
SpinKube releases will not be cut at a certain cadence; rather, project maintainers may advise that a new release be cut upon the addition of new features. | ||
|
||
The installation guide of the SpinKube documentation will display SpinKube release matrices and a features changelog. Marketplace maintainers can reference changes to this document. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if the operator cuts a new release Y that has a feature F we want to explain on the docs. But, since we're on SpinKube release Z (which has a version of the operator Y-1) we can't explain the new feature F on the docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The SpinKube releases document (say releases.md
) will display the releases but the entire set of docs are not tied to a certain release. Ideally you'd be able to toggle the installation guides for each SpinKube release but i am not sure if our docs CMS supports that
|
||
## Alternatives Considered | ||
|
||
This could just be documented with compatibility matrixes (such as [this one](https://github.com/spinkube/documentation/pull/253/commits/e93aed2d5b30d2c220289572acc80b3dc4e4a448)). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My default is to prefer some kind of relative matrix - rather than only having "blessed" single-version-compatibility (because that's ~impossible in upgrades through in a real cluster, where you need old-and-new versions to be compatible for at least the duration of operator-shim-and-workload upgrades).
Could you expand on why you think this is non-viable (and expand on how we should handle upgrade compatibility?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By single version compatibility, do you mean all 4 projects releasing the same version number? That is not the proposal of this SKIP. The proposal is to add some marketing lingo on top of a matrix that says SpinKube 2.0 is shim 0.17, operator 0.4 etc
No description provided.