Proposal is to extend this so tooling makers can attest to a given version. We can dedup across versions in the build process i.e. it may see a repo tagged several times, but the metadata will only be pulled once.
Proposed values (for discussion):
swagger.
openapi2.
openapi3 (currently supported tag).
openapi30.
openapi31.
This should allow the publication/ingestion mechanism to remain fairly straightforward and automated. The approach of course needs to be socialised with the community in an effort to get traction on tagging across repositories and repository providers.
User Story
As a tooling maker I want to register my tool's support for a given version of OpenAPI.
Detailed Requirement
The library gulpfile.js/lib/processors/awesome-openapi3-processor.js implements the method APIs.guru developed for collecting tooling through GitHub tags. This mechanism has legs as it is:
Proposal is to extend this so tooling makers can attest to a given version. We can dedup across versions in the build process i.e. it may see a repo tagged several times, but the metadata will only be pulled once.
Proposed values (for discussion):
This should allow the publication/ingestion mechanism to remain fairly straightforward and automated. The approach of course needs to be socialised with the community in an effort to get traction on tagging across repositories and repository providers.