Skip to content

Proposal to archive this repository #317

Open

Description

@princerajpoot20

As part of the 2026 community goals (more details here: asyncapi/community#3495), we conducted an audit of all repositories. The summary of the findings can be found here: asyncapi/community#3495 (comment).

As suggested by @Pakisan here: https://github.com/orgs/asyncapi/discussions/3612#discussioncomment-19216780, we are proposing to archive this repo.

Reference to the conversation:

I am opening this issue to gather feedback and approval from the code owners of this repository.

Tagging all code owners for their feedback and approval.
@derberg @fmvilas @dalelane @char0n @GreenRover @mboss37 @GeraldLoeffler @rcoppen @SrfHead @lbroudoux @ivangsa @whitlockjc @damaru-inc @CameronRushton @VisualBean @dpwdec @iancooper @amparosancho @gramss

Activity

  1. github-actions commented on Oct 29, 2026

    @github-actions

    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.

  2. changed the title [-]Proposal: Move tck into bindings[/-] [+]Proposal to archive this repository[/+] on Oct 29, 2026
  3. Pakisan commented on Oct 29, 2026

    @Pakisan
    Member

    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:

    • 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

    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 .md description near to .json to always be in sync:

  4. ivangsa commented on Oct 29, 2026

    @ivangsa

    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

  5. Pakisan commented on Oct 30, 2026

    @Pakisan
    Member

    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

    Here they are: https://asyncapi.pavelon.dev/bindings/

  6. iancooper commented on Oct 30, 2026

    @iancooper
    Collaborator

    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

  7. Pakisan commented on Oct 30, 2026

    @Pakisan
    Member

    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

    You can left concerns here asyncapi/spec-json-schemas#665

  8. ivangsa commented on Oct 30, 2026

    @ivangsa

    understood, and make sense 👌

  9. iancooper commented on Oct 30, 2026

    @iancooper
    Collaborator

    @Pakisan Looks good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions