Which tools wants to stay up to date with the spec release?

[jonaslagoni]

In the release process it states:

Notify maintainers of the following repositories that the first feature is merged and that release will be produced and therefore they need to start preparing for it:

• JavaScript Converter
• Playground
• React component
• Markdown template

Should tool owners pledge to want to update their tools for spec releases i.e. should be pinged during the release process? Not sure if we should formalize this or should it just happen naturally? 🤔

I would love to add Modelina to that end.

@magicmatatjahu I guess the studio needs to replace the playground as well?

Potentially also generator, and I would add ts-nats-template and dotnet-nats-template if it does.

Personally, I would love to have tooling better integrated into the release process in some way or another. Not sure if adding the tools to this list is "enough" 🤔 What do you think?

[derberg]

I think it would be cool to ping anyone that is interested, even folks outside AsyncAPI org. We could have some mailing list or something, where release coordinator would drop a message. Something like this?

[magicmatatjahu]

@magicmatatjahu I guess the studio needs to replace the playground as well?

Yep, in the next release it will be replaced by Studio.

Potentially also generator, and I would add ts-nats-template and dotnet-nats-template if it does.

Of course no one is blocking you to update your templates. I think we chose these projects because they have the biggest impact on the whole current asyncapi tooling ecosystem (we can remove markdown template but I remember about updating). I would just add generator as you mentioned and maybe glee as well.

[jonaslagoni]

I think it would be cool to ping anyone that is interested, even folks outside AsyncAPI org. We could have some mailing list or something, where release coordinator would drop a message. Something like this?

Could be as simple as that yes 🤔

Of course no one is blocking you to update your templates. I think we chose these projects because they have the biggest impact on the whole current asyncapi tooling ecosystem (we can remove markdown template but I remember about updating). I would just add generator as you mentioned and maybe glee as well.

Of course, but if you don't follow the development each day, it might be hard to get notified about when you can start preparing your tools.

[derberg]

yeah, I definitely get your point and totally agree. Of course, we can tell people to subscribe to releases in spec using GitHub features, but this would not be enough and is already too late for some maintainers.

I don't know if there is a better solution than a generic mailing list that anyone can subscribe to 🤔

[magicmatatjahu]

One of the problems that I also see in updating tools is the situation that occurred in the previous release. On the same day as the tools were updated we also merged changes in spec/json-schemas/parser on the release branch - this caused situations when e.g. people needed to know about the changes but did not have a "pre-release", which could be tested in tools. We needed some kind of freeze period in which we have the spec/json-schemas/parser merged (of course on the pre-release branch) and people can use them in the tools, e.g. 1-2 weeks. We are waiting for the tools update and then we do a full spec and tools release. What do you think?

[derberg]

yeah, very valid point really, and super related to this issue. What is the point of sending a memo if we added new release candidate a day before the release. Tbh I'm not sure 2weeks is enough....

but on the other hand, you know RC is technically not needed to test out things, with node you can use specific commit revision...I know it is not ideal, but yeah 🤔

[magicmatatjahu]

Tbh I'm not sure 2weeks is enough....

For minor changes maybe it will be enough, but for major I agree, we need at least 1-2 months

but on the other hand, you know RC is technically not needed to test out things, with node you can use specific commit revision...I know it is not ideal, but yeah 🤔

Yeah, it can be workaround but for freeze period I mean that we don't add new things to the spec, so people have guarantees that last RC is final RC and we only wait for tools :)

[jonaslagoni]

As it is somewhat out of scope for this issue, I think you should create a suggestion in the spec repo with the concerns @magicmatatjahu.

[magicmatatjahu]

@jonaslagoni Here we go #667 😄

[jonaslagoni]

What if we tagged all asyncapi/tsc_members once a release is stable, i.e. almost ready to merge as in this issue? That way all maintainers have a chance to update the tools 🙂

[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 ❤️