Kamelets versioning or Kamelets Catalog definition

[squakez]

As we've started some draft work [1] to think alternative distribution model for Kamelets Catalog, I think we can collect some feedback about the possibility to version Kamelets (and catalog), if that makes sense. Right now we don't have a native way to create a versioning for a given Kamelet, so the most immediate workaround is to use a naming convention and apply it manually (ie, timer-source_v1).

Let's collect feedback and comments on possible scenario around if and how we'd like to support versioning in Kamelets.

[1] #4350

[github-actions]

This issue has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!

[Exether]

We definitely thought about this option (renaming kamelets in case of non compatible change), but it seemed unpractical for the following reasons:
Kamelet management:

• It can be difficult to evaluate if a change needs to create a new version.
• In case of a jar changes, several kamelets could require a name change.
• This leads to a lot of duplication as we also need to keep the previous kamelets.
• It will be difficult to tell if an old kamelet can be removed to keep the overall number low.

Routes and config management:

• It requires all routes using this kamelet to be updated to use the new one.
• It requires to change all the property names for this kamelet in all deployments.
• There would be a risk to have several versions of the same library if we freeze older kamelets versions dependencies.