-
Notifications
You must be signed in to change notification settings - Fork 89
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
Propose versioning policy for Upjet-based providers #314
Conversation
Signed-off-by: Jean du Plessis <[email protected]>
|
||
### Unavoidable breaking changes | ||
|
||
Due to a reliance on the upstream Terraform providers and prior instances where they introduce breaking changes in minor version releases, we cannot guarantee that a minor version bump will never introduce a breaking change. |
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'm not familiar with the history here. Is the issue with terraform provider minor releases that have contained undocumented/surprising breaking changes? Or deliberate breaking changes, noted in the release notes, but released as a minor version bump?
If the former, then this caveat is probably necessary. But if it's the latter, it seems we could just bump our major version. This would mean that the upjet provider's major version number would no longer match the terraform provider's major version number, but that seems like a reasonable price to pay for standard semver guarantees related to breaking changes.
1. The `major` version number **MUST** be incremented if the `major` version number of the Terraform provider it is generated from is incremented. | ||
2. The `minor` version number **MUST** be incremented when new functionality is released or when [unavoidable breaking changes](#unavoidable-breaking-changes) are introduced. | ||
3. The `patch` version number **SHOULD ONLY** be incremented for a release containing **ONLY** bug fixes and no new features. | ||
4. A release that increments the `minor` or `patch` version **ONLY**, **MUST** be backward compatible. |
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.
This is in conflict with the unavoidable breaking changes caveat from point number 2.
|
||
The webhooks should be implemented as part of the provider to simplify deployment. | ||
|
||
Upjet provides high-level libraries that make writing these converters fast and robust for specific API changes. |
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.
Having never written a conversion webhook, I'm left wondering where to find these libraries, and a link would be great. But if it's obvious to those with more k8s/golang experience where to find them, you don't need to add it on my account alone.
Description of your changes
This PR proposes introducing a versioning policy for Upjet-based providers.
I have:
make reviewable
to ensure this PR is ready for review.Addedbackport release-x.y
labels to auto-backport this PR if necessary.How has this code been tested
N/A