Hello Pasquale, I think it makes sense.
This will mean moving the following project and the related crds in base, right? https://github.com/apache/camel-k/tree/main/java/crds Il giorno lun 2 set 2024 alle ore 17:18 Pasquale Congiusti < pasquale.congiu...@gmail.com> ha scritto: > 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/ >
