OpenAPITools/openapi-diff

#772

· DrSatyr opened

on Apr 22, 2025

[OpenAPI 3.1.0 support] JsonSchema type changes not handled.

OpenAP 3.1.0 Support

Bug

#745

· DrSatyr opened

on Feb 10, 2025

Comparing OpenAPI 3.0.1 to 3.1.0 does not work

OpenAP 3.1.0 Support

Bug

#755

· codesimplicity opened

on Mar 14, 2025

Add documentation for detectable breaking/non-breaking changes

Breaking/Non-Breaking classification

enhancement

#138

· kylerjensen opened

on Mar 26, 2020

Refactoring a schma with "$ref" results in false positive breaking change

Breaking/Non-Breaking classification

help wanted

Bug

#192

· jo-gre opened

on Oct 23, 2020

PUT new attribute backwards compatibility optional

Breaking/Non-Breaking classification

question

#251

· davidboden opened

on Jul 22, 2021

Adding a new optional property to the request/response body is considered backward incompatible.

Breaking/Non-Breaking classification

Bug

#264

· ekadetov opened

on Sep 24, 2021

False positive breaking change when making a required request body optional

Breaking/Non-Breaking classification

Bug

#329

· thake opened

on Jan 28, 2022

Removing a security scheme is considered incompatible

Breaking/Non-Breaking classification

question

#330

· thake opened

on Jan 28, 2022

Consider removal of deprecated elements as compatible

Breaking/Non-Breaking classification

Bug

#371

· kubamarchwicki opened

on May 5, 2022

Removing a Query parameter is considered a breaking change while removing a Request Body parameter isn't

Breaking/Non-Breaking classification

help wanted

Bug

#412

· AdamBosseBS opened

on Sep 15, 2022

Do not fail with breaking changes when major version is bumped

Breaking/Non-Breaking classification

enhancement

Feature

#460

· jdnvn opened

on Feb 3, 2023

Increasing the maxLength property for a String field is considered a breaking change while Decreasing it is considered as Backward compatible.

Breaking/Non-Breaking classification

Bug

#461

· Hazel-John opened

on Feb 7, 2023

False positive when adding optional property

Breaking/Non-Breaking classification

Bug

#490

· spg opened

on Mar 14, 2023

[2.1.0-beta.6 and oas-3.1.0] Request body property data type change is detected as compatible or no_change

Breaking/Non-Breaking classification

Bug

#528

· nagarro-aditya opened

on Jun 2, 2023

incompatible api diff result when one of property in model becomes not required

Breaking/Non-Breaking classification

Bug

#535

· lbxxxxx2a opened

on Jun 22, 2023

Removing a mandatory or optional property in the input data : breaking change ?

Breaking/Non-Breaking classification

question

#599

· Kourtakis opened

on Dec 19, 2023

No backward compatible changes in Schema are marked as Compatible

Breaking/Non-Breaking classification

Bug

#611

· awaqas opened

on Jan 16, 2024

Deleted or renamed properties are marked as backwards compatible

Breaking/Non-Breaking classification

Bug

#673

· Patrick-Bayer opened

on Jun 14, 2024

Schema description update should be considered as a metadata change

Breaking/Non-Breaking classification

duplicate

Bug

#694

· stefk-fipto opened

on Aug 13, 2024

Markdown output does not specify whether the change is backward-compatible or not

Breaking/Non-Breaking classification

Render capabilities

#766

· tuananhlai opened

on Apr 5, 2025

--json output is absurdly huge

enhancement

Render capabilities

Feature

#562

· MajorDallas opened

on Sep 8, 2023

Support for detecting changes in webhooks

OpenAP 3.1.0 Support

Feature

#793

· caristu opened

on Jun 17, 2025

Changing request field type from <code>string</code> to <code>oneOf: string, number</code> shouldn't break

Breaking/Non-Breaking classification

Bug

#797

· nesk opened

on Jul 4, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

2.2.0

Unify Handling of allOf/anyOf and oneOf in Diff logic

[OpenAPI 3.1.0 support] JsonSchema type changes not handled.

Comparing OpenAPI 3.0.1 to 3.1.0 does not work

Add documentation for detectable breaking/non-breaking changes

Refactoring a schma with "$ref" results in false positive breaking change

PUT new attribute backwards compatibility optional

Adding a new optional property to the request/response body is considered backward incompatible.

False positive breaking change when making a required request body optional

Removing a security scheme is considered incompatible

Consider removal of deprecated elements as compatible

Removing a Query parameter is considered a breaking change while removing a Request Body parameter isn't

Do not fail with breaking changes when major version is bumped

Increasing the maxLength property for a String field is considered a breaking change while Decreasing it is considered as Backward compatible.

False positive when adding optional property

[2.1.0-beta.6 and oas-3.1.0] Request body property data type change is detected as compatible or no_change

incompatible api diff result when one of property in model becomes not required

Removing a mandatory or optional property in the input data : breaking change ?

No backward compatible changes in Schema are marked as Compatible

Deleted or renamed properties are marked as backwards compatible

Schema description update should be considered as a metadata change

Markdown output does not specify whether the change is backward-compatible or not

--json output is absurdly huge

Support for detecting changes in webhooks

Changing request field type from <code>string</code> to <code>oneOf: string, number</code> shouldn't break

2.2.0

List view