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

Separate output destination of samples generated from OAS3 #156

Open
ackintosh opened this issue May 26, 2018 · 3 comments
Open

Separate output destination of samples generated from OAS3 #156

ackintosh opened this issue May 26, 2018 · 3 comments

Comments

@ackintosh
Copy link
Contributor

Description

Related comment:
#80 (comment)

I think that the scripts under bin/openapi3 should output its results into samples/openapi3.

Currently, only PHP is following the rule above:

The samples of same lang will have differences if those have generated from different OAS version.
As supporting the OAS3 specific features progresses, differences between the samples from OAS2 and OAS3 becomes bigger.

Existing the difference between the samples from OAS2 and OAS3 is correct. so I think the samples should be put each appropriate location separately.

@wing328
Copy link
Member

wing328 commented May 28, 2018

I totally see your point. Originally I used the same folder for the sample output so that I can review more easily using git diff to ensure the output by OAS v2 and v3 spec are almost identical.

I agree moving forward there will be more difference as we support more features in OAS3.

Let's resume this discussion after the 1st stable release.

@jmini
Copy link
Member

jmini commented May 28, 2018

I agree to delay this discussion after our first release...

I am not sure if we need to generate and commit results for OAS2 and OAS3 inputs for each combination of generators. The result should be identical and when this is not the case, this might be an issue with the swagger-parser component that is doing the conversion for us.

@jimschubert
Copy link
Member

I think this was an issue for a while, but we relied only on oas2 spec outputs. Now that oas3 support is more inline with oas2, I think it's less of a concern.

Should we close this?

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

4 participants