The catalog info file is read by backstage to expose the existence of
our API specs into that service catalog. It allows custom metadata on
each entity where we previously added the API version information,
including the stability level.
Since the stability information on specs was moved from document wide to
per operation. This means that there is no global stability level for an
entire API spec after the "pivot date" where the new style specs are
being generated.
Therefore it make no sense to populate these fields anymore since they
will be incorrect. It is better to show less data than incorrect data.
Before this changeset the operation would error out as it could not read
x-snyk-api-version on the generated specs.
The catalog info file is read by backstage to expose the existence of our API specs into that service catalog. It allows custom metadata on each entity where we previously added the API version information, including the stability level.
Since the stability information on specs was moved from document wide to per operation. This means that there is no global stability level for an entire API spec after the "pivot date" where the new style specs are being generated.
Therefore it make no sense to populate these fields anymore since they will be incorrect. It is better to show less data than incorrect data.
Before this changeset the operation would error out as it could not read x-snyk-api-version on the generated specs.