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

OpenAPI 3.1 support? #52

Open
mitar opened this issue Nov 1, 2021 · 7 comments
Open

OpenAPI 3.1 support? #52

mitar opened this issue Nov 1, 2021 · 7 comments
Labels
enhancement New feature or request

Comments

@mitar
Copy link

mitar commented Nov 1, 2021

Any plans to support OpenAPI 3.1?

@reuvenharrison
Copy link
Collaborator

This repo depends on https://github.com/getkin/kin-openapi which doesn't yet support OpenAPI 3.1.
Perhaps you could share an example of your specs and the expected diff?

@mitar
Copy link
Author

mitar commented Nov 3, 2021

Yes, I see this issue: getkin/kin-openapi#230

I am currently evaluating tooling we use to see if we are ready to migrate to 3.1 ourselves. It seems not yet. :-)

petkostas added a commit to petkostas/openapi.tools that referenced this issue Jul 18, 2022
philsturgeon pushed a commit to apisyouwonthate/openapi.tools that referenced this issue Jul 18, 2022
@reuvenharrison reuvenharrison added the enhancement New feature or request label Nov 17, 2022
@Schandekar1
Copy link

When we can expect 3.1 support?

@eumenhofer
Copy link

I know this is an ongoing issue. Side note, most projects i've seen are struggling to provide 3.1 support for their tooling, does anyone know why it's so challenging?

@reuvenharrison
Copy link
Collaborator

reuvenharrison commented Feb 2, 2024

Hj @eumenhofer,
oasdiff relies on https://github.com/getkin/kin-openapi to parse OpenAPI specs.
This project itself is stuck in regards to 3.1 support as you can see here.

I think this is a good example of the dynamics that are holding back OAS 3.1 support across the entire community.
To put it in my own words, I'd say that the OpenAPI end users consider the required investment to be too costly for the expected value.

Needless to say, if you or anyone else reading this thinks that the investment is worthwhile I would be happy to discuss.

Reuven

@LasneF
Copy link

LasneF commented Mar 8, 2024

:( starting green field all my spec are 3.1 , leveraging tooling that support it , spectral , api management
still even if green field support of oasdiff would have been great, looking on the small diff (but annoying) things between OAS 3.1 and 3.0 , it s more likely that kin-openapi is a bit zombie, not so active :( that put your (very nice) project in danger :(
especially as OAS 3.2 (no breaking promise ) and 4.0 are coming ...

@derbylock
Copy link
Contributor

derbylock commented Apr 11, 2024

From my point of view, the only promising replacement for kin-openapi which supports OpenAPI 3.1 is a libopenapi https://github.com/pb33f/libopenapi. But during my last test I found that it lacked some features in reference resolution and its errors handling was not good enough.
I suppose it is possible to make a new version for oasdiff based on libopenapi, but firstly the libopenapi library should be fixed itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants