should binding specs be tied to specific versions of the AsyncAPI spec?

[GeraldLoeffler]

(Opened as requested in asyncapi/bindings#63 (comment).)

When implementing the Anypoint MQ binding spec (PR asyncapi/bindings#63) my instinct was to state the version of the AsyncAPI spec (initially 2.0.0, then 2.1.0) that this binding spec was written against/for. There is nothing specifically in the binding spec that requires that exact version of the AsyncAPI spec. But it did feel "right" to state clearly that the binding spec was written assuming the features of that version of the AsyncAPI spec.

Question: should binding specs state the version of the AsyncAPI spec they assume?

[magicmatatjahu]

I understand problem, but only use case which I see is situation when we will introduce in the next versions of spec drastic breaking changes for appropriate channels, servers and in other places where you can and want define binding. I don't see any other way.

When we talk about implementation of your idea, we can support in the binding definition next to the bindingVersion the asyncapiVersion (or specificationVersion) field with form to check that satisfied with spec semver, like here, so you will end with binding definition:

bindingVersion:  ...
asyncapiVersion: ">=2.0.0 <3.0.0",

Additionally I think that we should also support this field (if we decide to supporting it) in the custom extensions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[magicmatatjahu]

I think it's still relevant. We should discuss that problem also for extensions. cc @GeraldLoeffler @jonaslagoni (you're interesting in bindings/extensions topic so I ping you)

[GeraldLoeffler]

i agree it's relevant @magicmatatjahu , but i personally don't have capacity to champion it

[magicmatatjahu]

@GeraldLoeffler No problem, I make a triage to check all stale issues :)

[jonaslagoni]

Honestly, I think this will automatically be picked up for 3.0, as we will need to figure out how bindings still make sense and how they should be handled.

[jonaslagoni]

As this issue was just bought up in the 3.0 spec meeting when we discussed asyncapi/bindings#113.

And as this issue just become something we have to think about for 3.0, I wanted to tag all of the binding codeowners for input. @rcoppen @lbroudoux @dalelane @damaru-inc @CameronRushton @KhudaDad414 @derberg @fmvilas

What do you folks think about bindings and the spec relation, how should we handle that?

[jonaslagoni]

@GeraldLoeffler would you have any interest in championing this?

[fmvilas]

I think the binding spec should explicitly state the minimum and maximum version of the core spec it supports. Just like we do with Generator templates but not necessarily in a machine-readable way. I mean, can be just something that's in the Markdown file of the binding spec.

[magicmatatjahu]

but not necessarily in a machine-readable way. I mean, can be just something that's in the Markdown file of the binding spec.

@fmvilas but we need to have information (on tolling side) against what definition we need to use to validate the given binding. May find that binding version 1.0.0 is compatible with <2.3.0 but no longer with 2.4.0 (as example) - similar to extensions, they should have also info about compatible versions of AsyncAPI.

[derberg]

as @fmvilas mentioned we need min/max like in generator, and like @magicmatatjahu wrote, we need it as part of schema, so tooling can check that out

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[jonaslagoni]

Still relevant.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️