Hi folks, in the past we've discussed the opportunity to move the specification of Kamelet from Camel K to Camel since Kamelets have been a general concept for some time. I'd like to set the ground for a shared decision on what to achieve. I will create a JIRA, but, before, I'd like to understand if we all agree with the following points.
1. We should move the CRD from Camel K to the Kamelet catalog repository. It's important we familiarize ourselves with the Kubernetes API management policy, above all with deprecation policy [1] and make sure to avoid any change that would break any public clients compatibility. The API may be used by any application/tool outside Apache Camel and it is vital to make sure we respect the contract. Kamelets API has been GA in v1 since a while and it's quite stable. I suggest discussing any non-trivial change publicly in order to always understand the potential impact outside the Apache Camel ecosystem. 2. We should rethink the bundling process for the provided Kamelet catalog in Camel K. Above all, we need to align with the expected behavior provided by Camel core. The distribution model that it seems more obvious is to leverage the catalog distributed as a dependency with Camel core. That means that, by default, the Kamelet version used for catalog provided Kamelet at runtime will be the one distributed with the given core version. Let me know what you people think. Thanks and regards, Pasquale. [1] https://kubernetes.io/docs/reference/using-api/deprecation-policy/
