How do we handle major version changes of dependant libraries?

[jonaslagoni]

Reason/Context

Modelina is approaching v2, while there is no breaking changes in it's API, the output models will be a breaking change for anyone who has generated models from v1.

So my question is, how do we handle multiple major versions in the CLI?

[derberg]

imho the only right way is CLI major. Doesn't matter that breaking change comes from external library instead of CLI code itself. If user output will change, so should the major version.

@Souvikns @boyney123 @magicmatatjahu

[jonaslagoni]

Would it not be possible to have user-specified versioning in some way 🤔?

I guess having more then one dependant version is a bit too much 😅

[derberg]

you mean like a flag to specify which modelina you want?

[derberg]

similar situation is with asyncapi/generator#925 as when we release generator 2.0 templates that use generator prop config to specify that their template is valid with generator but only prior 2.0 will stop working. So pipelines will stop/fail because of it, so new CLI should also be released 🤷🏼

we should probably already do it when parser 2.0 was introduced here

[jonaslagoni]

Yea, it's a weird situation... The easiest is by far just the most recent version.

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

[derberg]

@Souvikns anything from your side?

[Souvikns]

@Souvikns anything from your side?

nothing from my side, when the dependent libraries version changes it automatically pushes and releases a minor version and when we create new commands or change anything to the CLI(core CLI logic ) we can then release a major version.

[derberg]

@Souvikns but if in dependent library there is a major release, and for example output changes, then it is a breaking change. This is why in tests we also do test the output. And yeah, in case of recent Modelina v2 release, the automated bump of course failed #848 because the output did not match.

This is purely major release. Major is not only if we change commands or other stuff in CLI

[Souvikns]

Yeah, in this case, we have to update the CLI manually, but should that be a major release for the CLI? Is a major release in a dependent library equal to a major release in CLI? I think we should first define what is a major release in CLI. Now that CLI will have its first major release as v1. What kind of changes in CLI will result in the next major release for CLI?

We can maybe swap or install certain dependent libraries in runtime or use already globally installed versions of our dependent library. I think we can pull this off, just need to update the commands to keep support for older versions of the library.

[derberg]

@Souvikns I think we need to do an exercise and try to forget that certain command depends on some other library like modelina or bundler. Basically imagine CLI includes all the logic, like CLI has bundle logic or models generation logic. Now, once you modify the output of models generation inside CLI, it means you influence the output of what users expects to get. If users with version 1.1 get certain models output, they expect it won't change with 1.2 and 1.3 or 1.3.1 and whenever the output changes - it is a breaking change, as it is possible that different output is also breaking their application

So strategy here is that it doesn't matter if modelina release v2 or v3, what matters is - are CLI commands or CLI output affected? If modelina release v3 because they break some library API, but output of models is the same - this is not major for us.

We can maybe swap or install certain dependent libraries in runtime or use already globally installed versions of our dependent library. I think we can pull this off, just need to update the commands to keep support for older versions of the library.

you mean how it is done with parser-js? that we support different versions? Doing it for all dependencies will be a super demanding job

[Souvikns]

Makes sense, so we only release a major version when any output in CLI is changed or if we have a new command added to CLI.

[derberg]

new command is not affecting the output, it is like a new stuff that can be minor

for me major is:

• anything that changes output of given command (might be related to major release of one of libraries or just some refactor on commands that we could do)
• any command rename or removal
• any flag rename or removal

thoughts?

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

[Amzani]

still relevant

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