Collectively working on 3.0.0

[jonaslagoni]

As we are getting closer and closer to a 3.0.0 release in the spec, I thought it would be a good idea to figure out how we can best collaborate on the efforts to figure out how and what needs to be done.

Cause 3.0.0 spec release is not just a spec release, it means adapting all our tools as well.

For the spec, all the current issues that seem like they would require a breaking change to solve, are listed under the milestone: https://github.com/asyncapi/spec/milestone/18. It does not necessarily mean all issues must be added to the spec for 3.0.0, but we need to consider them and whether a simple feat release can solve them later.

For tooling, everything starts at the parser level, after that the rest follows. However, we cannot change the parsers before we have some concrete changes in the spec.

For the parsers, this could be a unique opportunity to introduce the parser-api to future-proof our parsers for future breaking changes in the spec.

After the parsers have been addressed, we can focus on the rest of the tooling:

• Parser TCK
• Generator
• Templates
• ... Take your pick: https://github.com/orgs/asyncapi/repositories

Suggestion

We start a new recurring meeting (the same as our current SIG meeting), once a week dedicated to collectively push the efforts of 3.0.0. Maybe you just want to follow along in the development, or maybe you want to help out, this would be the place to join!

Would you be interested in joining?

Do you have other ways we can do this? 🙂

[magicmatatjahu]

I wonder if for the 3.0.0 release we should have some freeze period, where we have approved changes for 3.0.0 and then for about 1.5 months (or maybe 2 months) we have time to add support for 3.0.0 in all our tools and also people who have their own authoring libraries could also have time to add support.

[jonaslagoni]

It is for sure something we can discuss how we can and should handle the release process 🙂 Also for further references, so we can figure out what works and what doesent.

[smoya]

As we have chatted offline, I'm totally in for the meeting. Giving visibility of the work behind v3.0.0 release would also make people be involved in the trend.

It does not necessarily mean all issues must be added to the spec for 3.0.0, but we need to consider them and whether a simple feat release can solve them later.

I think this is one of the efforts we should focus first. It goes in relation with @magicmatatjahu 's comment, since once we have the list of features to include in v3.0.0, the effort should move into moving through all RFC stages. It might happen (not likely) that some of those finally are discarded, but we would anyway have an idea of what big changes tooling will need to adopt.

Regarding the freeze period, sure I think at that exact point we should make an estatement and close the list of inclusions. I won't specify an exact period of time to implement thing in tooling just to avoid broken promises but we can all have an estimation.

Just my 2cents.

[jonaslagoni]

Yea, I agree. It is something we can bring up in such a meeting to fully discuss 🙂

[doc-jones]

Because I don't know what I don't know.

What are the criteria for a breaking changes releases for AsyncAPI?
Is there a release schedule for AsyncAPI or are releases are a response to a large number of issues plus availability to build?
Are the answers easily available some place where I have neglected to look, yet?

[jonaslagoni]

What are the criteria for a breaking changes releases for AsyncAPI?

A change is considered breaking if it is not backward compatible. More preciously, any change to the spec that forces end-users to update their AsyncAPI documents or tooling. Introducing new keywords is not considered a breaking change, but refactoring existing keywords can be, the same as removing them. I.e. the changes suggested in asyncapi/spec#618 will be a breaking change, as the current AsyncAPI documents won't be compatible with the new structure.

Is there a release schedule for AsyncAPI or are releases are a response to a large number of issues plus availability to build?

Release is happening up to 4 times a year, you can read more about it here: https://github.com/asyncapi/spec/blob/master/RELEASE_PROCESS.md

What those releases include, depends on what is ready to be merged i.e. are in RFC-3 stage. If nothing is in RFC-3 stage, no release. If 1 issue is in RFC-3, then that determines the version change.

For major version changes, it depends on your point of view, but it would be best to bundle multiple breaking changes together, as it is such a radical change, that a single breaking change will probably not be enough for people to have the incentive to update their tools and documents.

But it can of course happen 😄

Did that clarify your questions? 🤔

[doc-jones]

I know what a breaking change is. heh! But I like how thorough your response is.

I see you've pointed to changes resulting from a particular issue. Does AsyncAPI have criteria defined that distinguish when a breaking changes release is required or simply a dot release?

Yes! The RELEASE_PROCESS is the type of thing I was hoping you could point me toward. Thanks very much. 😄

I guess I'm curious whether documenting the general criteria for determining what type of release is needed might not exist or maybe be helpful at this point?

[jonaslagoni]

Does AsyncAPI have criteria defined that distinguish when a breaking changes release is required or simply a dot release?

Nothing is written down, I can only refer back to what a breaking change is, which determines when what is required 😄 This is the "first time" we are introducing a breaking change, so everything is new.

Should we have something written down? It would probably be a good idea yes, as well as learn from how we do it this time and make some retro perspective afterward 😄

[quetzalliwrites]

In today's SIG meeting, we discussed potential times to start holding this new meeting.

My suggestion is that perhaps we can hold this one week to be compatible in EU timezone and then the next week in Americas timezone... or should only 1 time be picked for the first few ones that works for all areas? :)

I myself am curious to join because I want to learn and keep up to date w/ newer spec changes.

[derberg]

imho we need to pick one time.

atm we see that the largest engagement in the community is located in between India - Americas. So we should target a time that enables both.

[derberg]

I'm all with having these meetings as long as:

• we do not do it weekly as this requires huge involvement and full-time focus = pressure. At least IMHO 😄
• we respect the principle of async work and that these as a sync call and not a place where decisions are being made
• we do not call it, like organize it as a typical working group, where you set it up first with a fixed group of people and later on it is hard for anyone new to get into it. It is ok to invite people, advertise the meeting and get as many people as possible, but just not document it as a formal working group

[smoya]

we do not do it weekly as this requires huge involvement and full-time focus = pressure. At least IMHO 😄

I can agree once a week could be too much, at least by now.
On the opposite, once a month seems not enough imho. I suggest we go twice a month, with the possibility of changing it later if required (both increasing or reducing frequency).

we respect the principle of async work and that these as a sync call and not a place where decisions are being made

Totally +1. Decisions should be always taken publicly via GH Issues or related.

we do not call it, like organize it as a typical working group, where you set it up first with a fixed group of people and later on it is hard for anyone new to get into it. It is ok to invite people, advertise the meeting and get as many people as possible, but just not document it as a formal working group

I think calling it working group does not imply a closed group of people. I see it as a way of referring to a just that, a group of people with a shared concern in mind that work together somehow to solve issues and move forward.

[derberg]

yes, 2 a month, or call it every 2 weeks 😄

[jonaslagoni]

We, of course, need to start somewhere, so let's start with that 👍

[smoya]

Once the recurring event (or the first) gets created, we should add an entry to #163 :)

[jessemenning]

Late to this discussion, has this meeting been established? If so, would love to join. If not, would be in favor of it starting.

[jonaslagoni]

Not yet @jessemenning!

I plan to take this up first thing next week and push it forward 🙂

[jonaslagoni]

Based on the feedback I suggest we start up next week Wednesday 19th, 5 PM CET, to match EU/US/INDIA timezone as well as we can 😄 The meeting will be recurring bi-weekly.

We will have the same format as for our SIG meetings, where we create an issue for each meeting where everyone is welcome to add items to the agenda.

The meetings will be entirely community-driven for gathering thoughts, ideas and discussing problems or a place for one to keep up to date with the progress of v3.

Any agreements/disagreements/outcomes of discussions SHALL be written down them into corresponding issues/pr's/discussions afterward, no final decisions are made on these meetings.

If this format is not working, we can always change it, but this gives us a way to start 🙂

Any objections, thoughts?

@derberg anything I can do to set up these recurring meetings or should I pass the stick to you?

[jonaslagoni]

That's the plan as I understand it, right @derberg 😄?

[derberg]

if you are in asyncapi-users google group, then yes

the only thing that is not clarified here is where you wanna meet?

zoom is not cool as video recording upload is manual, unless @jonaslagoni you want to handle that, you can get YouTube rights to upload those. I suggest using restream and doing it as a live stream. Just not to lose time with video management. It always hurts me to do it manually for SIG meetings. Restream have scheduled events, so I can always schedule new one for you, get invite link and put into invite.

zoom also is not cool as we do not have one official AsyncAPI account, so Jonas or someone would have to create some meeting I guess, or ask @fmvilas to do it as I think he is doing it for SIG from private account that he pays for on his own.

tbh, I want to propose the same change for SIG meetings. Just get rid of any manual steps as much as possible and use AsyncAPI official tools everywhere possible

[jonaslagoni]

I vote for restream yes 🙂 Less work = more work 😆

[jonaslagoni]

@derberg is one of the limitations with restream not that it has a hard time handling many people in a call? I.e. say we are 15 in a call, how can it handle that in terms of showing the stream etc?

[derberg]

well, I don't think we ever had 15 folks there in a call, I think the max was 6 during the conference live discussion about AsyncAPI future and it was working well afaik. In the end, we can always switch the meeting tools in the middle if this one is not working well.

[derberg]

ok folks, you have first meeting scheduled for you: #235

tl;dr this is studio link https://studio.restream.io/guest/ejh3MFh2VtxtaKVadEgFnV_DhG_h-1I?event

Will create calendar invite in AsyncAPI calendar in few minutes