The reasons why I suggest drop the Swagger 2.0 support are: 1. Some functions such as "contract compatibility checking" and "contract style checking" doesn't support Swagger 2.0, so that's weird we support Swagger 2.0 in some functions while don't support in other functions. 2. OpenAPI 3.0 growing and Swagger 2.0 will be replaced eventually
If we really need to support Swagger 2.0, we can mark it deprecated and give plan on when to drop it entirely. About 0.2.0 release, I think we can release it now. Features could be implemented in afterward versions. sen sun <asd992825...@gmail.com> 于2019年11月18日周一 上午9:44写道： > > This road map is very excellent. I agree with the above development route. > But for the "Scaffold code generation" feature, maybe we can keep the > compatibility with swagger2.0? > There are a lot of features to be implemented. > What features do we want to include in the next release (0.2.0)? > > Daniel Qian <chanjars...@gmail.com> 于2019年11月17日周日 下午9:14写道： > > > Hi toolkit team, > > > > We had a short talk on wechat about what should we do next on Toolkit > > project. I think before we start we should have a discussion about the > > roadmap, because Toolkit is a project composed by different functions. > > > > Below are the main functions I can think of, and features can be > > categorized into one of them: > > > > 1. Scaffold code generation: generate scaffold code from contract > > file. Currently we support Swagger 2.0 and OpenAPI v3. > > 2. Contract generation: reverse-engineering generate contract from > > code. Currently we support Swagger 2.0 and OpenAPI v3. > > 3. Contract style checking: check contract style. Currently we support > > OpenAPI v3. > > 4. Contract compatibility checking: check whether new contract is > > compatible with the old. Currently we support OpenAPI v3. > > 5. Server side code match checking: check whether server code, such as > > @Controller, @RequestMapping, etc, matches what are described in > > contract. Already implemented, but it's based on text diff not based > > on semantics, I think there are some limitations. > > 6. Client side code match checking: check whether client code matches > > what are described in contract. Maybe we can check the client written > > in Feign. Not implemented yet. > > 7. Service side auto/semi-auto testing: auto or semi-auto generate > > legal and illegal request payloads to test whether server response > > what are described in contract. Not implemented yet. > > 8. Mock server: to help client code do unit or integration testing, > > the key is the mock server should do every request validations that > > are described in the contract and responses' schema match the > > contract. Not implemented yet. > > 9. Documentation generation: generate various documentation format > > from contract, such as docx, pdf, html, markdown, etc. Not implemented > > yet. > > 10. Helpful tools based on above functions: such as cli, maven plugin, > > gradle plugin, eclipse plugin, intellij plugin. Partially implemented. > > > > Besides, should we still supporting Swagger 2.0? I think we should > > move on to OpenAPI 3.0. > > > > Any ideas are welcome. > > > > -- > > Daniel Qian > > Apache Committer(chanjarster) > > blog：https://chanjarster.github.io > > github：https://github.com/chanjarster > > segmentfault: https://segmentfault.com/u/chanjarster > > -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
