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

[RFC] Handle OpenAPI 3.1 BC Breaks #130

Open
Tracked by #128
marcelthole opened this issue Oct 21, 2021 · 2 comments
Open
Tracked by #128

[RFC] Handle OpenAPI 3.1 BC Breaks #130

marcelthole opened this issue Oct 21, 2021 · 2 comments
Milestone

Comments

@marcelthole
Copy link
Contributor

It's nice to see the work for the OpenAPI 3.1 standard. I think a big part are the deprecated fields or type changes like:

  • The nullable keyword has been removed from the Schema Object (null can be used as a type value).
  • the type can be now an array with the type and null
  • exclusiveMaximum and exclusiveMinimum cannot accept boolean values (following JSON Schema).
  • See more at Stoplight Blog and OpenAPI Release Notes

How would you like to handle these breaking changes?
My first idea was to duplicate the spec files into a 3.0 and 3.1 Folder and use them according to the given OpenAPI version.
The positive parts are that static code analysis or the IDE knows which type of Object is used and the user don't have to handle multiple types. For example the type as string in OpenAPi 3.0 and type as array in OpenAPI 3.1 with null item. Also the spec could be validated and it's not necessary to add version switches for fields that are required or not.

The second Idea is to "convert" the Structure into the existing Spec Files. So a type with two items in OpenAPI would be an oneOf or if the type includes null the nullable flag would be added. But then you need to convert the items back to the new structure if you want to write a OpenAPI 3.1 file. The other part is, that you then support a converter from OpenAPI 3.0 to OpenAPI 3.1 and i don't think this is a feature to maintain in this library.

The last solution is to try to handle both versions into a single file. But that could be hard because of the breaking changes in OpenAPI 3.1. Even OpenAPI 3.1 didn't make a release without breaking changes. It could be complex to handle it here.

My preferred solution is version one because of the strict types and the clear break between Version 3.0 and 3.1
The Version and Specs for Version 3.0 are already feature complete and all changes effects only the new Spec files and couldn't break anything.

I look forward to your opinion. Maybe this should be clear before we make more changes into #128 ?

@cebe
Copy link
Owner

cebe commented Nov 3, 2021

My first idea was to duplicate the spec files into a 3.0 and 3.1 Folder and use them according to the given OpenAPI version.

I thought about that but the changes are very minor so adding a new set of files for every version is a bit of overkill. That would also result in a number of duplicated class names and it is hard to import the correct one when working with the library.

@cebe cebe added this to the 1.7.0 milestone Feb 9, 2022
@cebe cebe modified the milestones: 1.7.0, 1.8.0 Apr 20, 2022
@cebe cebe mentioned this issue Apr 20, 2022
3 tasks
@philsturgeon
Copy link

philsturgeon commented Apr 27, 2022

the type can be now an array with the type and null

It's a bit more than that, it could be type: [object, array, string] or any combination of types. :D

Hopefully this article explains it a bit better. https://www.openapis.org/blog/2021/02/16/migrating-from-openapi-3-0-to-3-1-0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants