Skip to content
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

Come up with uniform versioning scheme for methods #408

Open
MicahZoltu opened this issue May 18, 2023 · 1 comment
Open

Come up with uniform versioning scheme for methods #408

MicahZoltu opened this issue May 18, 2023 · 1 comment

Comments

@MicahZoltu
Copy link
Contributor

There are several possibilities here:

  1. add version parameter to the end - I think this is mostly backward compatible, if it isn't added just assume v1
  2. add version parameter at beginning - not backwards compatible, benefit is ???
  3. all methods accept 1 object with version as top-level value then args - ???
  4. add new method for backwards incompatible changes - similar to engine api
  5. new method which says which version the api is and move the entire api forward with new version updates
  6. ??? probably a lot more possibilities that haven't been thought through

Originally posted by @lightclient in #383 (comment)

@MicahZoltu
Copy link
Contributor Author

I am partial to (1) or (2). I like (2) long term as it in theory allows for partial JSON parsing to deduce version prior to fully parsing the payload, but I agree that (1) allows us to retroactively add versioning to all existing methods which is really compelling.

epheph added a commit to DarkFlorist/execution-apis that referenced this issue Jun 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant