-
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
RFC: 0110 framework/cli compatibility assurance #111
Conversation
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 think we need to rethink our entire protocol versioning model
@eladb @RomainMuller This is ready for another review. I think the main issues to address are: Thanks |
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.
The current proposal does fully address the problem of a new framework version that requires a new CLI version as it still leaves quite a lot of potential for error by developers:
- They can forget to write an integ test
- The bump of the protocol version can be messed up (happened many times)
Let's take this all the way and just eliminate one direction of compatibility by requiring CLI to always be >= framework. We already push users to upgrade their CLIs and already have cases where this is required (even if users don't use a new feature), so let's just keep it dead simple.
380a98a
to
947ba44
Compare
…k-rfcs into epolon/compatibility-strategy
@eladb @RomainMuller @rix0rrr I made the adjustments according to the new schema versioning we implemented. Have a quick look? |
Rendered version
Closes #110
By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache-2.0 license