`asyncapi --version` should also output version of other asyncapi dependencies

[derberg]

trafficstars

So instead of version of AsyncAPI CLI only we should also list generator and others

https://github.com/asyncapi/generator/pull/818/files#diff-c1cc304e56dd03cbb5cf65c32d83c9b7ab069800b2ce780249ac87d320e76789 is one of main reasons. For example in case of generator and templates, it is super important to know that you are using proper generator version. So we need an easy way for CLI user to check that out with one command

Thoughts? @Souvikns @magicmatatjahu @boyney123

[Souvikns]

So we need an easy way for CLI user to check that out with one command

Yeah, I agree with this, also since CLI is implementing other tools, should CLI be able to install specific versions of the tool on the go? So users can change the generator version they want to work with commands like asyncapi install @asyncapi/[email protected]

[magicmatatjahu]

@Souvikns I don't think so that it's good idea, due to fact that API for given tool can change between version, so for example, in newest parser we switch from singleton parser instance to the Parser as class, so API and also exports from module changed, so calling parse was changed.

[derberg]

ok, since we agree on that, the question is not on technical details.

afaik --version is something we get out of the box from oclif. So in case of this feature, we are talking about overwriting --version flag with custom implementation, right?

[Souvikns]

What would be better, to have a section in the release documentation talking about the different version of asyncapi tools it depends on, Or have it in CLI's --version flag or both?

[derberg]

--version flag is most important. For release notes we always link PRs, and it is easy to figure out.

[github-actions[bot]]

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:

[derberg]

this one is still very much needed

[thulieblack]

This issue is part of the AsyncAPI Bounty Program, interested contributors need to follow the guidelines below to ensure fairness and timely completion of assigned tasks:

Task Assignment

The assignment of tasks will be prioritized in the following order:

• AsyncAPI maintainers (from any repository)
• Regular contributors (individuals who have merged three or more pull requests)
• Other (if an individual doesn't fall under the above, the maintainer can determine the criteria i.e regular volunteers, etc)

We encouraged everyone to apply as long as the task is for you (falls under your skill set). We will not be using the first comment - get assigned method for assignments. Instead, we will provide 3 days to consider all individuals interested before assigning any bounty task.

Deadline

To maintain accountability and ensure the timely completion of the deadline for this task will be 4- 6 weeks from the date of assignment. If a contributor requires an extension on their task, it should be communicated and approved by the maintainer.

Issue Tracking and Updates

Contributors must provide weekly updates on the task they are working on to help maintainers stay informed of progress. If a contributor fails to provide an update, they will be reminded via a ping. If a contributor fails to provide an update after three pings over three weeks, we will assume they have silently dropped the issue, and it will be reassigned to someone else.

Issue Drop-outs

Any contributor who drops an assigned issue will be penalized and will not be eligible to participate in the bounty program for 6 months. We understand that unforeseen circumstances can arise, and dropping an assigned issue may be unavoidable in some cases. However, we believe that enforcing this penalty is necessary to ensure the effectiveness of the bounty program, respect maintainer time, and honor the efforts of other contributors who could have solved the issue but were unable to do so due to the drop-out.

We encourage all contributors to follow these guidelines to ensure a fair and timely completion of tasks assigned through our bounty program.

[mediba123]

I agree with the suggestion that the asyncapi --version command should output the version of other AsyncAPI dependencies. This would provide users with more comprehensive information about the software's version and the underlying components it relies on. It would also help users to identify any potential compatibility issues between their version of AsyncAPI and its dependencies. Overall, this would be a valuable addition to the command and would enhance the user experience.

[aeworxet]

I would like to work on this issue.

[aeworxet]

I think two issues (this + https://github.com/asyncapi/cli/issues/38) is just enough to not jeopardize delivery of both.

So I would propose addition to Bounty Program rules:

'Bounty Program Participant can choose up to two any Bounty issues for simultaneous delivery.'

[derberg]

@aeworxet please add your comment to https://github.com/orgs/asyncapi/discussions/541#discussioncomment-5652222 so we do not forget

@thulieblack as we did not have a rule to block someone from doing 2 issues at the same time, are you ok that @aeworxet will pick 2?

[thulieblack]

As long as @aeworxet delivers I don't think that will be a problem😊

[aeworxet]

Switch --version is reserved by oclif itself, I can only write separate command version which will gather versions of AsyncAPI tools used:

$ ./run --version
@asyncapi/cli/0.40.3 linux-x64 node-v16.17.0


$ ./run --help
All in one CLI for all AsyncAPI tools

VERSION
  @asyncapi/cli/0.40.3 linux-x64 node-v16.17.0

USAGE
  $ asyncapi [COMMAND]

TOPICS
  config    CLI config settings
  generate  Generate models and template
  new       Creates a new asyncapi file
  start     Start asyncapi studio

COMMANDS
  bundle    bundle one or multiple asyncapi documents and their references together.
  config    CLI config settings
  convert   Convert asyncapi documents older to newer versions
  diff      Find diff between two asyncapi files
  generate  Generate typed models or other things like clients, applications or
            docs using AsyncAPI Generator templates.
  new       Creates a new asyncapi file
  optimize  optimize asyncapi specification file
  start     Start asyncapi studio
  validate  validate asyncapi file
  version   Show versions of asyncapi tools used


$ ./run version
"version" CLI argument invoked

Would that do?

[derberg]

And there is no way to override or extend it? I think it anyway do not work well, as -v is not supported afaik

[aeworxet]

Possibility to override/customize --version output of oclif troubled great minds for years: https://github.com/oclif/oclif/issues/254

And it doesn't seem to be possible without making manual patches to @oclif/core because as one user said

--version is baked into Main.

Another user at some moment proposed two workarounds for this issue, but approach #1 uses deprecated packages and approach #2 uses hook functionality which basically does the same thing I had already proposed to do without a hook (hook is invoked on execution of a separate command and I don't see a necessity to introduce one more layer of abstraction.)

Example code: https://github.com/aeworxet/asyncapi-cli/commit/5bc9ce0d28273c2fc9c59f46dccde8aa6bb6991b

[aeworxet]

[derberg]

hey, yeah, I think version is better than workaround with hook. Problem is though that it is not aligned with current guide https://github.com/asyncapi/cli#command-structure-and-patterns

• version is not verb
• also version is not functional command here so should be under config imho, asyncapi config version or event asyncapi config version list, but I do not think there is a use case for more commands there, like that someone would like to change version of parser or anything like that 🤔

[aeworxet]

Bounty Program Timeline

Category	Assigned on (by GitHub)	Started on (by BP rules)	Due (by BP rules)	Draft PR submission	Final PR submission	Final PR merge
Medium Level	2023-04-27	2023-01-05	2023-06-09 (Friday of sixth week)	2023-05-12 (Friday of second week and updated on every Friday)	2023-05-26 (Friday of fourth week)	2023-06-09 (Friday of sixth week)

Please note that dates represent deadlines, not specific dates, so if the goal is reached sooner, it's better.

[derberg]

@aeworxet congrats on completing your first bounty issue

@thulieblack on to you, not sure if you have some copy/paste message for people on how to claim bounty payment, so yeah, leaving that communication up to you

@aeworxet I guess you will make a submission in one call once context-related issue is completed

[thulieblack]

Hey @aeworxet , congratulations on completing your first bounty issue.

This is how'll claim your payment:

1. Go to AsyncAPI Open Collective page
2. Submit an expense and add details for the bounty issue
3. Voila! you get your coins🤑 !!