This Feature request is related to asyncapi plugin
Context
The Asyncapi plugin helps to generate automatically the events and services but some missing parts lead to a duplicated work on markdown to well prepare the adoption
Details
[ ] Versioned services
Versioned Services
Asyncapi plugin does well the extraction of event versions but in contrary it handles the service extraction just by spec info.title and not considering the version, in real scenarios the service name does not change but the version so at the end of generation the result includes two services with the same name that breaks the vizualization and graph parts
example
Having two specs as following will produce two separate services which are the same originally
info:
title: MyService - V1.0.0
version: 1.0.0
info:
title: MyService - V2.0.0
version: 2.0.0
The real requirement seems to be having two specs with the same Title ( as they represent the same service ) but different versions
info:
title: MyService
version: 1.0.0
info:
title: MyService
version: 2.0.0
The idea is to do the same versioning principe done already for event versioning, that means Generating the versioned services by the same title and introducing exp. latest, v2.0.0, v1.0.0 versions
Benefits
As EventCatalog allows rendering the asyncapi spec at service level it is important to have two distinct versions of service and their dedicated Async Spec in each version
Considerations
Take into account the Latest service version in visualizer
Consider the latest version in NodeGraphe and mermaid representations in service listing page
Motivation
As EventCatalog allows rendering the asyncapi spec at service level it is important to have two distinct versions of service and their dedicated Async Spec in each version
Have you read the Contributing Guidelines on issues?
Description
This Feature request is related to asyncapi plugin
Context
The Asyncapi plugin helps to generate automatically the events and services but some missing parts lead to a duplicated work on markdown to well prepare the adoption
Details
Versioned Services
Asyncapi plugin does well the extraction of event versions but in contrary it handles the service extraction just by spec
info.titleand not considering the version, in real scenarios the service name does not change but the version so at the end of generation the result includes two services with the same name that breaks the vizualization and graph partsexample Having two specs as following will produce two separate services which are the same originally
The real requirement seems to be having two specs with the same Title ( as they represent the same service ) but different versions
The idea is to do the same versioning principe done already for event versioning, that means Generating the versioned services by the same title and introducing exp. latest, v2.0.0, v1.0.0 versions
Benefits As EventCatalog allows rendering the asyncapi spec at service level it is important to have two distinct versions of service and their dedicated Async Spec in each version
Considerations
Motivation
As EventCatalog allows rendering the asyncapi spec at service level it is important to have two distinct versions of service and their dedicated Async Spec in each version