Using completed tasks as release date for 3.0 #944
Comments
|
Yeah, agree! We should use this as the "roadmap" for when to release it instead of dates. |
|
After asyncapi/community#737 it seems asyncapi/server-api#294 needs to be added to the list because of the studio and CLI usages. |
|
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 |
|
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. |
|
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? |
☝🏼 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? |
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. |
|
but there is big difference:
basically I think: |
|
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 🙂 |
|
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 |
|
I have made no plans for that 😄 |
|
About the next public call, we can have it the week after.
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. |
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. |
|
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. |
|
I'm all for it. Let's release it on the 25th. By then we may even get Glee supporting it too. |
|
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. |
|
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, 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. |
|
there was a wrong link to |
|
Studio updates:
✅
|
|
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 😆 |
|
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? |
|
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)
This is already automatic, we just have to ensure the pipeline don't fail etc, but no manual work should be necessary.
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
👌 @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. |
|
As promised, here's the link to the discussion: https://github.com/orgs/asyncapi/discussions/924. |
can confirm ☝🏼 was a bug in react component and below PR will fix it |
|
just marked below as solved
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 |
and others
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.
The text was updated successfully, but these errors were encountered: