-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Introduce version in the trigger spec #613
Comments
We should also look at versioning scalers independently from the core, but that might be another issue. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. |
This issue has been automatically closed due to inactivity. |
Re-opening as I think it's time to do this. |
This issue has been automatically closed due to inactivity. |
I think this could be a huge headache because we'd have potentially twice or 3 times more code to maintain. I'm not saying no to this, but before starting with this, I'd like to have the versioning lifecycle defined and what users can expect from each version. |
Oh yes, I'm not saying that we should already implement this straight away but I think we have to do it. It's either this way, or we cannot make breaking changes to triggers unless we bump the API version for our whole CRD. Before I went in to detail, I wanted to see if we all agree this is something we should do. In terms of duplication, I'd say that this is just something we can isolate from the configuration parsing and share the logic (unless big things are being removed), but I think it's mainly for the way we configure things. With regards to end-to-end tests, I'd say we support current + current-1, but that's just a proposal |
Signed-off-by: Jinli Liang <paul.liang@rokt.com>
Introduce version in the trigger spec so that we can release new versions of the trigger specification without breaking customers.
This allows us to introduce new ways of describing things without having messy documentation and is easier to troubleshoot.
Use-Case
When a scaler decides to change things around by renaming fields, moving them around or introduce breaking changes there is no easy way to see the difference as a customer.
With clear versioning it would be more straight forward and the documentation can be built around it.
Current
Proposal
We could add a
version
to the trigger spec:Impact
The impact should be fairly minimal
v1
should be assumedThe text was updated successfully, but these errors were encountered: