You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Reacted by Steve Coffey, Christian Klotz, Jean Mertz, Xuanwo, Nikhita Raghunath, hackerman, Melvin, Zoe, Bart van Kleef, Márk Sági-Kazár and 3 more
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.
Hey folks! It's amazing to see everyone working together to make this happen. If the chat moved to slack, what was the outcome? It'd be great to get everyones efforts focused on the same project, and mark the others as deprecated so there's no further split efforts.
Reacted by Joseph Gardner, Taylor Barnett-Torabi, Stephen Townsend, Alex Ball, alc86, Oleg Arkhipov, Draget, Dkhusainov, Jan Cerman, Janis Walliser and 1 more
Hi, we could really use this in order to get DapperDox to support our OpenAPI 3 docs. What's the status of this, and is there anything I can contribute to move it along? No one seems to know what the outcome of the Slack chat was.
BTW there's a very similar discussion over at go-swagger/go-swagger#1122 (comment), not sure how the two organisations are related but they share contributors.
So, what needs to be done first & how do we split work? I don't have much time but I do want to move this forward. I don't know the codebase much yet.
@casualjim@morlay As I understand it work should start/concentrate around go-openapi/spec3? I'm guessing the parser would be a first step? @morlay Are you still down to work on this?
@fenollp
Here just my version https://github.com/go-courier/oas.
I don't really know how to start the migration from my version to go-openapi/spec.
We wrote package for different purpose. And it not easy to extract as a common one without fully communication.
And recently, I am lots of busy with my work.
If you have any idea to start the migration, I'm glad about be base on my codes.
Reacted by Bart van Kleef, Kaspar Lyngsie, Alex Ball, Márk Sági-Kazár, Brian Atlas, Jeremy Prevost, Wolfgang Werner, Volodymyr Dyptan, Sebastien Pouplin, Vladimir Sapronov and 21 more
Hey all.. seems the last update on this thread about what was going on, which direction OAS 3 was headed.. was a year ago. Can anyone put a close on this and let us know.. is OAS3 being supported in this project, go-swagger, or the kin-openapi project, which seems to have active development from just a few days ago and from what my go noob eyes can tell is more complete than other implementations? Which project should every go developer and project that intends to support OAS3 depend upon? More importantly.. is there a reason it hasn't been moved in to openapi codegen so that the one location most people turn to has the most active up to date implementation and documentation?
The close is: don't look here. I think openapi generator has come a long way since I started this project.
The spec3 repo has an up to date list of missing items in the readme.
Activity
vburenin commentedon Feb 16, 2017
Yes, there are plans. OpenAPI spec 3.0 is simply not ready.
sdcoffey commentedon Feb 16, 2017
Cool, I can live with that. Thanks for the quick response!
casualjim commentedon Feb 16, 2017
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:
wouter-b commentedon Dec 6, 2017
It has been 10 months now ;-)
Any news or an E.T.A.?
morlay commentedon Jan 3, 2018
@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 commentedon Jan 3, 2018
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 commentedon Jan 3, 2018
@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 commentedon Mar 9, 2018
Anything new on this front? Would love to see Open API 3.0 support
morlay commentedon Mar 9, 2018
@PhyberApex
There is an version https://github.com/morlay/oas which supported v3.
PhyberApex commentedon Mar 9, 2018
Any chance on getting it in here? Because I actually want it to be enabled here: https://github.com/DapperDox/dapperdox which uses this repo
~Cheers
14 remaining items
philsturgeon commentedon Jul 23, 2018
Hey folks! It's amazing to see everyone working together to make this happen. If the chat moved to slack, what was the outcome? It'd be great to get everyones efforts focused on the same project, and mark the others as deprecated so there's no further split efforts.
philsturgeon commentedon Aug 27, 2018
Bump :D
david-l-riley commentedon Oct 17, 2018
Hi, we could really use this in order to get DapperDox to support our OpenAPI 3 docs. What's the status of this, and is there anything I can contribute to move it along? No one seems to know what the outcome of the Slack chat was.
fenollp commentedon Nov 7, 2018
BTW there's a very similar discussion over at go-swagger/go-swagger#1122 (comment), not sure how the two organisations are related but they share contributors.
So, what needs to be done first & how do we split work? I don't have much time but I do want to move this forward. I don't know the codebase much yet.
@casualjim @morlay As I understand it work should start/concentrate around go-openapi/spec3? I'm guessing the parser would be a first step?
@morlay Are you still down to work on this?
gregmarr commentedon Nov 7, 2018
@fenollp very simplified story: go-openapi was created from go-swagger to make components of it reusable outside the go-swagger project.
morlay commentedon Nov 8, 2018
@fenollp
Here just my version https://github.com/go-courier/oas.
I don't really know how to start the migration from my version to go-openapi/spec.
We wrote package for different purpose. And it not easy to extract as a common one without fully communication.
And recently, I am lots of busy with my work.
If you have any idea to start the migration, I'm glad about be base on my codes.
distinctgrey commentedon Dec 18, 2018
Any update on OAS3 support? :-)
d1ndra commentedon May 14, 2019
@fenollp @morlay @casualjim
I'd like to help with the integration of OAS v3.0 as I'm planning on using it with DapperDox/dapperdox#63, any pointers on how I should go about integrating it? Looks like https://github.com/getkin/kin-openapi already has support for OAS 3.0
kevinduffey commentedon May 28, 2020
Hey all.. seems the last update on this thread about what was going on, which direction OAS 3 was headed.. was a year ago. Can anyone put a close on this and let us know.. is OAS3 being supported in this project, go-swagger, or the kin-openapi project, which seems to have active development from just a few days ago and from what my go noob eyes can tell is more complete than other implementations? Which project should every go developer and project that intends to support OAS3 depend upon? More importantly.. is there a reason it hasn't been moved in to openapi codegen so that the one location most people turn to has the most active up to date implementation and documentation?
casualjim commentedon May 28, 2020
The close is: don't look here. I think openapi generator has come a long way since I started this project.
The spec3 repo has an up to date list of missing items in the readme.
Updated the project's README
Updated the project's README and godocs
Updated the project's README (#129)