-
-
Notifications
You must be signed in to change notification settings - Fork 13
docs: Add CRD versioning ADR #712
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
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for stackable-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
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.
LGTM in general, just some small remarks
> [!TIP] | ||
> This approach can be used for fields which opt into optional (experimental) features but still providing the ability to customize using the field. Using `Option<T>` will push the responsibility of dealing with `None` (eg. using a default fallback value) to the operator. | ||
|
||
**TODO:** Can we detect the addition of an optional field and thus enable not needing to bump / introduce a new version? We *can* somehow reliable detect `Option`, but it is not guaranteed to be the `Option` (from the standard library) we expect. |
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.
I fear it's very complicated to determine this and I'm fine not automating this for now (and rely on human intelligence to determine if the version should bumped).
If we determine the breakingness however, I think we should be looking at the generated crd.yaml, not the Rust code. Maybe there are already some tools for that already ;)
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.
I fear it's very complicated to determine this and I'm fine not automating this for now
It is indeed very complicated. I would even say impossible to do it reliably (right). I just left this to note down a random thought I had.
If we determine the breakingness however, I think we should be looking at the generated crd.yaml, not the Rust code. Maybe there are already some tools for that already ;)
Sure, that also makes sense. If we would down that road, I would still explore defining this in Rust code. This would also enforce specific rules around code. But as stated above, this was mostly just a random thought which will be removed from the final ADR anyway.
Part of stackabletech/issues#642
Rendered