search

asyncapi / cli

CLI to work with your AsyncAPI files. You can validate them and in the future use a generator and even bootstrap a new file. Contributions are welcomed!
https://www.asyncapi.com/tools/cli
Apache License 2.0
185 stars 157 forks source link

v1.0.0 planning #251

Closed Souvikns closed 4 months ago

Souvikns commented 2 years ago

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

Good To Have

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

fmvilas commented 2 years ago

Great initiative, Souvik 👏

imabp commented 2 years ago

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.

derberg commented 2 years ago

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:

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 commented 2 years ago

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

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 1 year ago

@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:

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 commented 1 year ago

@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 commented 1 year ago

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[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

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 :heart:

github-actions[bot] commented 8 months ago

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

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 :heart: