Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

kate-goldenring
Copy link
Contributor

No description provided.


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.
Copy link
Contributor

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.

Copy link
Contributor Author

@kate-goldenring kate-goldenring Oct 31, 2024

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)).
Copy link
Contributor

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?)

Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants