Skip to content

PUT new attribute backwards compatibility optional #251

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

Open
davidboden opened this issue Jul 22, 2021 · 0 comments
Open

PUT new attribute backwards compatibility optional #251

davidboden opened this issue Jul 22, 2021 · 0 comments
Labels
Breaking/Non-Breaking classification Issues related to Breaking/Non-Breaking changes classification question
Milestone

Comments

@davidboden
Copy link

#136 made the PUT request incompatibility check stricter, considering an additional field as a breaking change. This makes sense for a scenario where updates are taking place, but is too strict if PUTs represent only inserts.

What would be the best way of optionally removing the strict handling of PUTs? Options could include:

  • Surfacing more information about how the changedOperation.isIncompatible() decision was made, allowing the user of the OpenApiDiff to use more granular information to decide whether it should be considered as a breaking change.
  • Adding a command-line flag to remove the PUT strictness for all cases in a run.
  • Writing some code to traverse the object graph for PUTs when the diff has completed and decide whether the strict PUT handling is what caused the incompatibility, and then ignore it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking/Non-Breaking classification Issues related to Breaking/Non-Breaking changes classification question
Projects
None yet
Development

No branches or pull requests

2 participants