Repository navigation
Consider removal of deprecated elements as compatible #371
Description
I'm using openapi-diff quite successfully to avoid accidental changes in the API (and therefore introducing a breaking change). We use it as a part of our pipeline.
The current struggle is: that sometimes one wants to introduce a breaking change (like the removal of obsolete API).
My initial idea would float around a two-step process:
- marking an element ad deprecated (keeping compatibility)
- removing the deprecated element
To do that, when processing the list of ChangedOpenApi#getChangedElements I'd need to know if the particular element is deprecatable and decide if the change is incompatible or not.
That looks to me like another SPI but I'm not sure if it's the direction. I know it's currently not possible and I'm not even sure if the direction of my thought even makes sense.
Activity
crisarmen commentedon Nov 17, 2022
rashvirgo commentedon Jan 23, 2023
+1
I was also looking for the same feature as requested by @kubamarchwicki. Any direction would be appreciated here. Thanks
joschi commentedon Feb 25, 2023
@kubamarchwicki Thanks for reporting this.
Strictly speaking, removing any previously available element is a breaking change, even if it was deprecated before.
BUT I think together with the option to allow breaking changes if the major version of the API has been bumped described in #460, this might make sense.
What do you think?
kubamarchwicki commentedon Mar 5, 2023
Totally. One way or another - to clean up the API is good.
From my own personal standpoint, we've treated
openapi-diffas an intermediary step to contract testing based approach. We moved from schema based verification to usages based tests - which allowed us to more efficiently work with the api.