OpenAPI version 3.0

[sdcoffey]

Are there any plans to support the 3rd version of the OpenAPI spec?

[vburenin]

Yes, there are plans. OpenAPI spec 3.0 is simply not ready.

[sdcoffey]

Cool, I can live with that. Thanks for the quick response!

[casualjim]

By the end of the month open api 3.0 will be finalized as a specification, then we can start implementing it. So it will be a little bit before we really have support for this. realistically it takes about 6-8 months for most tooling to start supporting open api 3.0. At least it took almost 12 months for tooling to catch up to the 2.0 version of the spec last time.

going to leave this open because I expect this question to start coming up more often.

Things I would like to see different from the current object model:

• No more go maps but sorted maps instead, so we have identical json generation
• custom serializers based on mailru/easyjson that preserve line number and perhaps character position.

[wouter-b]

It has been 10 months now ;-)
Any news or an E.T.A.?

[morlay]

@wboevink @easonlin404
I have create one for openapi-spec@v3 https://github.com/morlay/oas
Could you like to test it?

@casualjim I don't understand the third dependencies, so I restart to create this, instead of forking from https://github.com/go-openapi/spec3

[casualjim]

easyjson you mean?

the main thing is the use of golang maps is anoying because of their random order, there are people who use other tools who want a stable ordering. So I implemented an ordered map.

the easy json is so that it's easier and faster to serialize and deserialize specs, doing that with golang json is memory hungry. kubernetes etc have a 40k+ lines spec.

[morlay]

@casualjim Thanks.
Got it. I will try to merge my works to spec3.
easyjson generate lots of codes, need time to learn how it works.

[PhyberApex]

Anything new on this front? Would love to see Open API 3.0 support