v1.0.0 planning

[Souvikns]

I am opening this issue to plan for CLI v1.0.0 release. There is no set date for v1 this is just to plan and track our progress. We can have a date if everyone decides on it, but I think it is too early for that.

Must Have

• generator features  #9
  • feat: add generate fromTemplate command #221
• Add convert command #41
  • feat: add new convert command to CLI #188
• Update documentation [📑 Docs]: feat asyncapi typedoc #232
• Add integration testing for cli #389
• Enable users to use CLI without installing NodeJS #168

Good To Have

• Integrate asyncapi/diff in the CLI #58
  • feat: integrate asyncapi diff library using the diff command #135
• Integrate cupid in the CLI #47
  • feat: integrate cupid in cli using the relation command #143
• Make it easier to create templates and glee projects #184
• Add asyncapi optimize command #218
• Add asyncapi bundle command #219
• Integrate modelina to generate models #129
  • feat: integrate modelina to generate models #173

---

If you want to change anything from this issue just leave a comment.

Pinging all the code owners- @magicmatatjahu @derberg @boyney123

[fmvilas]

Great initiative, Souvik 👏

[imabp]

Thank you @Souvikns I was really waiting for this roadmap ..
Let's push it.

Also @Souvikns please add this to the above list, as its done now.

• add watch option #73
  • feat: add global specification watcher #220

[derberg]

Awesome initiative @Souvikns 👏🏼

I think we should first agree on what 1.0 means to all of us and then define the scope. I personally always consider features only as one of many requirements, and only features that are necessary or features that can potentially be changing a lot after its release and we want to give them some time to make sure they are stable.

in other words, for example bundle, optimize or cupid or others are not must-have for me for 1.0. They are just nice to have.

my perspective is that we first must enable anyone:

• to use the CLI and try it out (the issue I'm working on to expose binaries not only as npm package)
• we have good integration tests that ensure releases are not breaking production (you remember recent issues with CLI we were not aware as we got used to using CLI directly from source code)
• research how we could perform some user testing. Maybe plugin analytics and have support for checking user consent to share them with us

from features perspective, the only important ones could be generate and convert so 1.0 of CLI would automatically deprecate Generator and Converter CLIs

Thoughts?

[Souvikns]

from features perspective, the only important ones could be generate and convert so 1.0 of CLI would automatically deprecate Generator and Converter CLIs

Totally agree!

in other words, for example bundle, optimize or cupid or others are not must-have for me for 1.0. They are just nice to have.

Maybe we divide our scope into must-have and might-have so that we can create some kind of priority.

I think we should first agree on what 1.0 means to all of us and then define the scope. I personally always consider features only as one of many requirements, and only features that are necessary or features that can potentially be changing a lot after its release and we want to give them some time to make sure they are stable.

So roughly major versions are just stable versions that are safe to be used in production. So we don't release a new feature and say it is V1 but take some old well-developed and well-tested features as the scope (Still trying to figure out how versioning really works).

---

Could this be our scope

Must have well-tested features Features

• generate command
• convert command
• Enable cross-platform installation (installation without nodejs)
• Rich Documentation
• Have integration testing so that CLI doe not break in production again.

research how we could perform some user testing. Maybe plugin analytics and have support for checking user consent to share them with us

Not sure how we can do this for a CLI.

[imabp]

I liked this of putting the completely production grade things to v1.0.0

research how we could perform some user testing. Maybe plugin analytics and have support for checking user consent to share them with us

@derberg @Souvikns , we need a e2e framework for testing CLI,

Just like cypress for frontend, I got to know about "nixt", for e2e user testing in clis
https://github.com/vesln/nixt

We can try using this.

[derberg]

@imabp https://github.com/vesln/nixt is more for the topic of integration testing that I mentioned, so we actually use the CLI as end user, not just testing individual components, but commands directly

for user testing, I mean kind of reports that we can receive that tell us what commands user is using, etc.
but yeah, this is big topic, that requires research and discussion with community, so I'm also fine if it is dropped for 1.0
you can compare it to website, and google analytics we have there. Last time I checked it was possible also to send data to google analytics from backend apps too, like CLI, so this could be a solution.

Maybe we divide our scope into must-have and might-have so that we can create some kind of priority.

or we can just say what is must have, that you listed in your comment, and that it doesn't mean we freeze development and people can and should be adding features as they want, without any block from our side

[imabp]

@derberg , that sounds like a telemetry analysis topic.
Yes, google analytics can be integrated with CLI too using Google's Measurement Protocol Node Library

I have used rollbar a lot, its useful to track errors and reports.

Meanwhile, let's just first ship the things of what is required.

[derberg]

@Souvikns how about we push it through AsyncAPI Mentorship?

Must have well-tested features Features
generate command
convert command
Enable cross-platform installation (installation without nodejs)
Rich Documentation
Have integration testing so that CLI doe not break in production again.

so scope would be:

• reach 90% test coverage?
• enable cross-platform installation - windows chocolate left I guess?
• documentation - we have it already integrated with website. I think we are missing some cookbook, or a kind of advanced examples on different commands, like a show case of options
• github action to easily use AsyncAPI CLI - could be just a guide on how to use it in a workflow, maybe action is not needed
• simple integration tests that prove binaries work

What do you think.
I think such topic will easily enable contributor to become a maintainer after the mentorship

---

Regarding analytics, this is completely different topic. And we could put it under mentorship too

[Souvikns]

@Souvikns how about we push it through AsyncAPI Mentorship?

Yeah definitely. One question though will all these be different projects or a single project from CLI?

[derberg]

all under scope would be part of one project, project would be called Prepare CLI for 1.0 release. GitHub action could be a bonus scope. I just do not think it is super complicated really

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