+1 for releasing 0.2.0. We could get some feedback from community with this new release.
Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Mon, Nov 18, 2019 at 11:29 AM Daniel Qian <chanjars...@gmail.com> wrote: > > 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
