Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using completed tasks as release date for 3.0 #944

Closed
5 of 6 tasks
jonaslagoni opened this issue Jun 7, 2023 · 26 comments
Closed
5 of 6 tasks

Using completed tasks as release date for 3.0 #944

jonaslagoni opened this issue Jun 7, 2023 · 26 comments

Comments

@jonaslagoni
Copy link
Member

jonaslagoni commented Jun 7, 2023

In #880 we tried to figure out a specific release date, however, instead of using dates, I am proposing that we use tasks as the finish goal when we should release 3.0. So once all those tasks are complete, we can release it in whatever spec release period we are in. Of course, we can make guesses on when that will happen, but tasks talk.

The reason I am proposing this is because it's open source 🤷 Contributors have different priorities and things just take longer than expected, and sticking to a schedule in a non-paying (for most) environment just is not feasible or even to be expected 😄

So here are the remaining issues I propose all should be completed before release:

Specification:

For tooling this is what I think is the bare minimum needed to work with AsyncAPI:

For docs:

Of course, this does NOT mean that other libraries should not be updated or worked on in the meantime, this should just be the bare minimum that blocks the release of 3.0.

@fmvilas
Copy link
Member

fmvilas commented Jun 7, 2023

Yeah, agree! We should use this as the "roadmap" for when to release it instead of dates.

@jonaslagoni
Copy link
Member Author

After asyncapi/community#737 it seems asyncapi/server-api#294 needs to be added to the list because of the studio and CLI usages.

@Amzani
Copy link
Collaborator

Amzani commented Jun 27, 2023

Using completion of tasks as a criterion for the release of version 3.0 of the project sounds like a reasonable approach, considering the challenges of coordinating contributors and the unpredictable nature of open-source development!

We could use https://shapeit.app/ to make this visible and make it fun
shapeitapp/shapeitapp#18

@jonaslagoni
Copy link
Member Author

jonaslagoni commented Sep 7, 2023

I am suggesting that we cut our requirements way down to release v3 to just the very core that will enable others to update in due time.

This means that we are effectively only relying on asyncapi/generator#979 to be complete before we release v3, which already is almost done: asyncapi/generator#1017

For docs that means the only thing that is missing is merging asyncapi/website#2008.

What ever other tool that is updated at the time of the release, perfect, if not, also perfect. It will happen in due time, but at least it is not blocking v3 release.

This decision takes effect Thursday, September 14th using lazy consensus, unless a codeowner of the spec objects.

@fmvilas
Copy link
Member

fmvilas commented Sep 7, 2023

I agree with your statement, @jonaslagoni. I'm happy to consider adding the react component as a blocker since it's very close to being done. What do you folks think?

@derberg
Copy link
Member

derberg commented Sep 11, 2023

  • React-component -> Studio and HTML template
  • Basic docs migrated (the ones that we have for 2.x already)

☝🏼 these are must have for me

Docs generation is main use case for AsyncAPI. Even if company uses AsyncAPI for other things like code generation, broker management and other stuff - docs generation is another "easy to get" side effect.


What if we make an agreement that if there will be no volunteers to commit to put priority on given task, then it will not be taken into the scope?

@jonaslagoni
Copy link
Member Author

jonaslagoni commented Sep 11, 2023

What if we make an agreement that if there will be no volunteers to commit to put priority on given task, then it will not be taken into the scope?

Then it's the same as my proposal, just with a longer fuse.

If it makes it in time, it makes it, otherwise it won't 🤷

I just don't want it to block the release.

@derberg
Copy link
Member

derberg commented Sep 11, 2023

but there is big difference:

  • with your proposal, stuff that are considered important are not in scope
  • if we do not define a scope, we do not know if we talk about commitment that can be fulfilled by the end of September

basically I think: scope -> commitments -> release date and you first set the release date, and then adjust a scope to it

@jonaslagoni
Copy link
Member Author

jonaslagoni commented Sep 11, 2023

Let me just say it plainly, if we want to include anything extra than what I suggested above, we will need to find another person to coordinate that effort 🙂

I will of course finish off what is listed above. Once you all reach an agreement on what needs to change for us to release v3 (docs, code, and what not), and they are done, then I can step in again and help finish the last tasks as release coordinator to release v3.

We are already way above and beyond what I expected was needed as a release coordinator so this is where we need someone else to step up 🙂

Copy link
Member

derberg commented Sep 12, 2023

No worries, I think you made it pretty clear during our last public call. What are you plans for next public call? since we travel to AsyncAPI conference next week

@jonaslagoni
Copy link
Member Author

I have made no plans for that 😄

@fmvilas
Copy link
Member

fmvilas commented Sep 12, 2023

About the next public call, we can have it the week after.

What if we make an agreement that if there will be no volunteers to commit to put priority on given task, then it will not be taken into the scope?

This is super important IMHO. Let's try to make it happen but if we can't, we ship with whatever we have. I agree with this.

Also, folks, remember that the release date doesn't have to be the same as the communication/promotion/announcement date. If we see that some things are not done but they're close to being done, we can postpone announcing it. This way at least we get rid of the release duty.

@smoya
Copy link
Member

smoya commented Sep 12, 2023

What if we make an agreement that if there will be no volunteers to commit to put priority on given task, then it will not be taken into the scope?

When we talk about volunteers, aren't Code Owners of the repositories we talk about needed to be involved? Are those the final volunteers we refer in that sentence? I.e. Code Owners from https://github.com/asyncapi/asyncapi-react.
I mean we would need them in order to finally decide if they want to commit to it, even though they do not code the changes.

@jonaslagoni
Copy link
Member Author

jonaslagoni commented Oct 16, 2023

Mad release coordinator here 👼

With all the tasks being done that I proposed, and ontop of that react components, HTML template, markdown template, studio, generator, CLI, and parser all supporting v3, I am going to start the release process for v3 on the 25th of October.

With CI run times this probably means that the release will be done on the 27th.

We have achieved all the steps on the release process and then some. So unless a spec code owner vetoes this decision (@fmvilas @derberg @smoya @dalelane @char0n, vetoing also means replacing me as release coordinator with yourself 😉 ), that is what I am gonna aim for.

Regarding outstanding website and docs changes, I simply don't care, migration guide has been standing still for nearly two months, and so for the other changes. Either the website is ready for when the spec is released or it's not.

The same goes for any other small issues, they are either gonna be fixed at the time of the release, or it's gonna happen afterwards, but I see nothing else blocking the release process.

@fmvilas
Copy link
Member

fmvilas commented Oct 16, 2023

I'm all for it. Let's release it on the 25th. By then we may even get Glee supporting it too.

@smoya
Copy link
Member

smoya commented Oct 16, 2023

As I mentioned in this Slack thread, I want to clarify people that V3 Spec reference page will be out by then.

You have my 👍. Happy to help with any required stuff.

@derberg
Copy link
Member

derberg commented Oct 25, 2023

For me there are certain "basics that need to be done" or "unknowns" that block the release:


As spec code owner I cannot imagine giving 🟢 light to release, if the next day someone comes to me and asks about, for example, messageId and I do not know the answer.

Some of the things from above list (development related) can be done few days after release. For me critical is to know a commitment. Who can commit to resolve certain items as a priority.

So, yeah, I already wrote in #944 (comment) that setting any date without knowing if anyone commits to help is not going to work. We should really not follow the practice that we just set a date, and not care if people will make it or not.

I'm happy to help figuring out commitments and help pushing for answers.

@derberg
Copy link
Member

derberg commented Oct 26, 2023

there was a wrong link to messageId topic, updated to #978

@Amzani
Copy link
Collaborator

Amzani commented Oct 26, 2023

Studio updates:

We should suggest v3 conversion for old documents (the modal that suggest conversion I mean) as now we suggest conversion from 3.0 to 2.6 (which will even not work)

asyncapi/studio#832

Making sure latest parser is used

We need updates examples in Studio + also example of v3 should load on first interaction

asyncapi/studio#831

@derberg
Copy link
Member

derberg commented Oct 26, 2023

ok, so I got confirmation from @AceTheCreator that he will help with Documentation generation topic I mentioned and @alequetzalli will be there active helping to review and approve stuff I will be working on in Docs topic. So for this topics I'm pretty sure we will be ready by 15th November.

Also @jonaslagoni you have my full support with a release itself. We can do a fun live stream with beers and crackers, or champaign and strawberries, up to you 😆

@fmvilas
Copy link
Member

fmvilas commented Oct 27, 2023

That's great. Thanks for coming up with a date, @derberg. Let me also coordinate with @thulieblack for the announcement and marketing activities. I propose we release and announce v3 in December so we have time to prepare all the marketing material and plan stuff accordingly. Does that sound good, @derberg?

@jonaslagoni
Copy link
Member Author

jonaslagoni commented Oct 27, 2023

Thanks @derberg, that will definitely help make the progress specific as to what is needed 👍 Thanks @Amzani for creating the studio outstanding tasks 👌

So here is the cleaned-up task list (what is missing and in progress), do you mind double-checking @derberg to ensure I got everything? I have included everything BUT docs as I read it like you push that effort with help from @AceTheCreator and @alequetzalli. So the below list is what I will help bring awareness to 🙂

New tasks (not in progress):

Tracking list (tasks list already in progress)

Making sure latest React is bumped in HTML template and Studio

This is already automatic, we just have to ensure the pipeline don't fail etc, but no manual work should be necessary.

A confusion starts because of Pub/Sub and I think it is related to parser -> asyncapi/asyncapi-react#815. We need a clear answer what is the reason. How is this related to v3? as this confusion affects latest React component. We basically need a way for docs generation to say that prior 3.0 you get in the UI PUB/SUB the right way and starting from 3.0 you get RECIVES/SEND the right way.

This is just a problem with react components, parser explicitly tells what the operation is, if you want to revert it for v2 (as we do in react components), then it needs to happen in each individual tool. Linked it as a task in the list above asyncapi/asyncapi-react#815

Let me also coordinate with @thulieblack for the announcement and marketing activities. I propose we release and announce v3 in December so we have time to prepare all the marketing material and plan stuff accordingly. Does that sound good, @derberg?

👌 @fmvilas would it be possible for you to come up with a list of tasks and commitments as @derberg just did for the above activities?

@fmvilas
Copy link
Member

fmvilas commented Oct 27, 2023

👌 @fmvilas would it be possible for you to come up with a list of tasks and commitments as @derberg just did for the above activities?

Yes, on it. I'm gonna put together a suggestion for a marketing plan and discuss it with @thulieblack. Once we agree on how to proceed, I'll create tasks for it. I'll put a link to the plan here once it's done.

@fmvilas
Copy link
Member

fmvilas commented Oct 27, 2023

As promised, here's the link to the discussion: https://github.com/orgs/asyncapi/discussions/924.

@derberg
Copy link
Member

derberg commented Oct 30, 2023

A confusion starts because of Pub/Sub and I think it is related to parser -> asyncapi/asyncapi-react#815. We need a clear answer what is the reason. How is this related to v3? as this confusion affects latest React component. We basically need a way for docs generation to say that prior 3.0 you get in the UI PUB/SUB the right way and starting from 3.0 you get RECIVES/SEND the right way.

can confirm ☝🏼 was a bug in react component and below PR will fix it

asyncapi/asyncapi-react#795

@derberg
Copy link
Member

derberg commented Nov 16, 2023

just marked below as solved

Screenshot 2023-11-16 at 17 45 59

also majority of docs are in v3 subdomain - only missing PR is asyncapi/website#2317

my only concerns is:

@Amzani you can work on studio update to use latest react component

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants
@fmvilas @Amzani @smoya @derberg @jonaslagoni and others