Other members of the team expressed a desire to be able to see previous versions. Initially we said that could easily be done by checking it the specific commit and generating an updated swagger.yml. But using SwaggerHub's multiple version functionality is a much cleaner solution.
So from now on when we release a new version of the API, we'll also update and generate a new version of the unified schema file and store it here, tagged with the respective version. We'll then create a new version in SwaggerHub and copy the contents of the file to it.
This change covers updating the name of the existing swagger.yml and updating the guide to reflect this change in process.
Not long after writing and adding the guide on our OpenAPI documentation we stumbled across the fact we can maintain multiple versions in SwaggerHub.
For example we can have
Other members of the team expressed a desire to be able to see previous versions. Initially we said that could easily be done by checking it the specific commit and generating an updated
swagger.yml. But using SwaggerHub's multiple version functionality is a much cleaner solution.So from now on when we release a new version of the API, we'll also update and generate a new version of the unified schema file and store it here, tagged with the respective version. We'll then create a new version in SwaggerHub and copy the contents of the file to it.
This change covers updating the name of the existing
swagger.ymland updating the guide to reflect this change in process.