search

asyncapi / bindings

AsyncAPI bindings specifications
Apache License 2.0
71 stars 75 forks source link

feat: add AsyncAPI V3 compatible SQS binding definitions #261

Open dpwdec opened 4 weeks ago

dpwdec commented 4 weeks ago

Update to SQS binding definitions for AsyncAPI V3 compatibility.

255

derberg commented 2 weeks ago

@dpwdec hey, I noticed you introduced versioning for binding. The thing is that bindings atm should be aligned with spec, which means only the latest binding version should be in master. We are not extending AsyncAPI v2 any further, so should be with bindings for v2. So they should not be in master. In other words, current master should only store latest, which is v3

iancooper commented 1 week ago

@dpwdec hey, I noticed you introduced versioning for binding. The thing is that bindings atm should be aligned with spec, which means only the latest binding version should be in master. We are not extending AsyncAPI v2 any further, so should be with bindings for v2. So they should not be in master. In other words, current master should only store latest, which is v3

Whilst we are not extending AsyncAPI v2 any further, I don't think we necessarily want to ask folks to upgrade to V2 just to get fixes or extensions to a binding for a given provider. The upgrade to V3 might take some time for some users. I would agree that master should be V3 and that V2 should be the branch however

derberg commented 1 week ago

I get your point. We had the same convo for Kafka binding. Afaik it was around v3 release date. Till today there were no complaints that people need updates to v2 bindings

If we keep supporting v2, people are not motivated to move to v3. As org we do all we can to motivate to migrate, converters and other tools support it already, and supported them on release date.

If in bindings we wanna go away from that model, then imho it could be a decision all binding owners agree with, so we are consistent. But my recommendation is to really consider it, be worried about it only if there is really a request coming from the community to add something to v2 binding, and that it is critical and there is no other way to do it.

Once we let in v2 support for one binding, it is opening door for precedence to do it for other bindings, and event the spec, and you know EDA and AsyncAPI maintenance is complex enough with one version in place 😅

And in the end, if one day, we see there is a really critical reason to improve some v2 binding, then it can be done as "one-time-exception" with some dedicated branch/tag and clear story in issue/PR why we had to do it.