You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: