-
-
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 ;)
# ... | ||
spec: | ||
foo: 42 | ||
# Not setting the field at all |
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.
nit (optional): I find it easier to read this way
# Not setting the field at all | |
# Not setting the field at all |
|
||
## Change: Renaming a field | ||
|
||
A renamed field can **always** be modelled as a non-breaking change which is also backwards compatible, meaning that a newer version of a field can be converted back to an older version. |
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.
A renamed field can always be modelled as a non-breaking
From my perspective renaming a field is breaking. There are valid yamls before that are not valid after
Part of stackabletech/issues#642
Rendered