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
Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request. Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.
I don't threat anymore AsyncAPI as single document to work with, that's why it's important to be able to release different parts without any issues
I work with:
AsyncAPI document
AsyncAPI bindings
AsyncAPI components
That's why it's important to store them in one place. And that's why I also refactored JSON Schemas (not only remove typos, bugs, missing parts) asyncapi/spec-json-schemas#665
this repo contains only the bindings documentation README.md files
so I agree with merging this docs to where the actual json-schemas for the bindings are
but maybe we should reword the issue from "archive" to "merge with", or did I got it wrong
this repo contains only the bindings documentation README.md files
so I agree with merging this docs to where the actual json-schemas for the bindings are
but maybe we should reword the issue from "archive" to "merge with", or did I got it wrong
I'm not sure about merging. Each new version overrides previous one. Goal is archive this repo and restore bindings docs in json schemas
I guess the question is what happens to bindings. Bindings are the key to infrastructure automation using AsyncAPI - you can create relevant queues, topics, schemas from the information in an AsyncAPI document. That means that they can be quite complex, per broker. Adding them into the main repo would result in the need to accept change there for bindings. That might work fine, but we should ponder if that works. But, agreed that trying to lower sprawl is overall good
I guess the question is what happens to bindings. Bindings are the key to infrastructure automation using AsyncAPI - you can create relevant queues, topics, schemas from the information in an AsyncAPI document. That means that they can be quite complex, per broker. Adding them into the main repo would result in the need to accept change there for bindings. That might work fine, but we should ponder if that works. But, agreed that trying to lower sprawl is overall good
Yep. Agree
Complexity already reduced after JSON Schemas refactoring. They are living in own catalogue which allows run independent releases
Activity
github-actions commentedon Oct 29, 2026
Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.
[-]Proposal: Move tck into bindings[/-][+]Proposal to archive this repository[/+]Pakisan commentedon Oct 29, 2026
Hey! Here is my motivation
I don't threat anymore AsyncAPI as single document to work with, that's why it's important to be able to release different parts without any issues
I work with:
That's why it's important to store them in one place. And that's why I also refactored JSON Schemas (not only remove typos, bugs, missing parts) asyncapi/spec-json-schemas#665
Here is an example of bindings as independent entities: https://schemas.asyncapi.pavelon.dev/draft-07/bindings/
Here is an example of components as independent entities for better de-composition: https://asyncapi.pavelon.dev/jetbrains-plugin/typed-components/server.html
I propose to store
.mddescription near to.jsonto always be in sync:ivangsa commentedon Oct 29, 2026
this repo contains only the bindings documentation README.md files
so I agree with merging this docs to where the actual json-schemas for the bindings are
but maybe we should reword the issue from "archive" to "merge with", or did I got it wrong
Pakisan commentedon Oct 30, 2026
I'm not sure about merging. Each new version overrides previous one. Goal is archive this repo and restore bindings docs in json schemas
Here they are: https://asyncapi.pavelon.dev/bindings/
iancooper commentedon Oct 30, 2026
I guess the question is what happens to bindings. Bindings are the key to infrastructure automation using AsyncAPI - you can create relevant queues, topics, schemas from the information in an AsyncAPI document. That means that they can be quite complex, per broker. Adding them into the main repo would result in the need to accept change there for bindings. That might work fine, but we should ponder if that works. But, agreed that trying to lower sprawl is overall good
Pakisan commentedon Oct 30, 2026
Yep. Agree
Complexity already reduced after JSON Schemas refactoring. They are living in own catalogue which allows run independent releases
You can left concerns here asyncapi/spec-json-schemas#665
ivangsa commentedon Oct 30, 2026
understood, and make sense 👌
iancooper commentedon Oct 30, 2026
@Pakisan Looks good.