spec
spec copied to clipboard
asyncapi
chore: add more reusable objects to the components object
title: add more reusable objects to the components object
That PR adds more more reusable objects to the components object like External Documentation Object and Tag Object.
Tags and External Documentation objects are used in several places and it would be a good solution to "convert" them to reusable objects, not inline.
Kudos, SonarCloud Quality Gate passed! 
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
No Coverage information
No Duplication information
![sonarqubecloud[bot] avatar](https://avatars.githubusercontent.com/in/12526?v=4 "Published by a pub.dev verified publisher"){kind=small}
@KhudaDad414 Could you check the failing Check Markdown links job? I guess that after merging it https://github.com/asyncapi/spec/commit/f269234668a63653616ff7b3fc9a6b249c73ee5b it should be fixed, but it's not. Please correct me if I'm wrong.
@magicmatatjahu Why this PR is targetting next-major-spec instead of next-spec? I can't see where the breaking change is (most probably missing something).
As a minor comment, the title prefix would need to be feat:.
@smoya I thought it better not to add it to 2.X.X but to 3.0.0 despite the lack of breaking changes. As for chore: I don't know how the release process will behave and don't want to release 3.0.0-prerelease1 😅
@smoya I thought it better not to add it to 2.X.X but to 3.0.0 despite the lack of breaking changes. As for
chore:I don't know how the release process will behave and don't want to release3.0.0-prerelease1😅
Considering there is no BC and that it adds a really useful feature, I don't see any reason to not add this into 2.5 release that will happen in September.
While working on 3.0.0, we'll find a bunch of things that are not BC and could potentially be added to 2.x. However, IMHO, we must be careful not to overimprove 2.x because otherwise, there will be little incentive to migrate to 3.0.0 when it's done. This work was part of a 3.0.0 task and I'd consider it for 3.0.0 only.
While working on 3.0.0, we'll find a bunch of things that are not BC and could potentially be added to 2.x. However, IMHO, we must be careful not to overimprove 2.x because otherwise, there will be little incentive to migrate to 3.0.0 when it's done. This work was part of a 3.0.0 task and I'd consider it for 3.0.0 only.
Even though I'm afraid I have to disagree, I can say 👍 to both of you If you consider it is a good strategy to follow.
What can we do to move this forward, is it only reviews we need @magicmatatjahu ? 🙂
Kudos, SonarCloud Quality Gate passed!
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
No Coverage information
No Duplication information
@jonaslagoni
What can we do to move this forward, is it only reviews we need @magicmatatjahu ? 🙂
Yes. Here is also PR for json-schemas https://github.com/asyncapi/spec-json-schemas/pull/245
cc @derberg @fmvilas @dalelane
Kudos, SonarCloud Quality Gate passed!
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
No Coverage information
No Duplication information
Rebased with current next-major-spec. Could you check again? @derberg @fmvilas @dalelane Thanks!
I think that it could be merged :) I also have PR in json-schemas https://github.com/asyncapi/spec-json-schemas/pull/245 In ParserJS also https://github.com/asyncapi/parser-js/pull/639 (still draft - without tests)
cc @derberg @fmvilas
:tada: This PR is included in version 3.0.0-next-major-spec.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
