Update Q&A based on feedback from users #695
Conversation
docs/qna.md
Outdated
| 1. The founding members came to the conclusion that Swagger Codegen 3.0.0 beta contains too many breaking changes while they strongly believe 3.0.0 release should only focus on one thing: OpenAPI 3.0 support. | ||
| 1. We had concerns about the development practices, which seemed to be contributing to an unstable and insufficiently tested codebase. | ||
| 1. We could not agree on an efficient evolutionary strategy. The founding members felt it was important to move forward with OpenAPI 3.0 support, while maintaining backward compatibility with OpenAPI 2.0 in the same codebase. | ||
| 1. We found that the enhancements, bug fixes submitted for Swagger Codegen 2.x need to be submitted again for Swagger Codegen 3.0.0 branch. Otherwise, these changes will not appear in the 3.0.0 branch. Having to do the PR twice is not the best use of the community resource. |
There was a problem hiding this comment.
Isn't this just a consequence of the previous point? If so, consider leaving it out.
If you think the consequence is important, maybe just append to the previous point: "...in the same codebase, rather than maintaining two separate branches in parallel."
There was a problem hiding this comment.
Thanks for the feedback. It may or may not be the consequence of the previous point and that's why I think we should elaborate with a separate point.
In OpenAPI Generator, we maintain different branches for patch, minor and major (e.g. 4.0.x with breaking chagnes) releases and we regularly sync changes between these branches to reduce community effort in submitting duplicated PRs.
In other words, maintaining different branches for the project to evolve is perfectly fine but not having a practice/workflow to sync enhancements, bug fixes between branches is less than ideal.
(These are my opinions)
docs/qna.md
Outdated
| 1. We could not agree on an efficient evolutionary strategy. The founding members felt it was important to move forward with OpenAPI 3.0 support, while maintaining backward compatibility with OpenAPI 2.0 in the same codebase. | ||
| 1. We found that the enhancements, bug fixes submitted for Swagger Codegen 2.x need to be submitted again for Swagger Codegen 3.0.0 branch. Otherwise, these changes will not appear in the 3.0.0 branch. Having to do the PR twice is not the best use of the community resource. | ||
| 1. The community-driven version has a much more rapid [release cycle](https://github.com/OpenAPITools/openapi-generator/releases/) (weekly patch release, monthly minor release) so users do not need to wait for several months to get a stable release. | ||
| 1. Having a community-driven version can bring the project to the next level with reliable releases and a clear [roadmap](https://github.com/OpenAPITools/openapi-generator/blob/master/docs/roadmap.adoc). | ||
|
|
||
| #### Has anything been done in attempt to address the issues before deciding to fork Swagger Codegen and maintain a community-driven version? | ||
|
|
There was a problem hiding this comment.
The following line mentions "SmartBear (Ron, Hugo)." I would suggest leaving Ron and Hugo's names out of this, again to make it less personal. You could just leave it as "SmartBear" or "the project owners" or "the other project owners" (if some of you were also owners).
|
I have pushed a commit based on other feedback I got. Changes are:
|
|
Thanks @jmini If no further feedback from anyone, I'll merge it into the master over the weekend. |
|
PR merged into master. Thanks for all the review and feedback. |
* update qna based on feedback from users * Improvements * minor fix to typo
PR checklist
./bin/to update Petstore sample so that CIs can verify the change. (For instance, only need to run./bin/{LANG}-petstore.shand./bin/security/{LANG}-petstore.shif updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in.\bin\windows\.master,4.0.x. Default:master.Description of the PR
(details of the change, additional tests that have been done, reference to the issue for tracking, etc)