The answer is simple: kamelets are part of Camel-k like camel-k-runtime, so the camel-kamelets is part of the camel-k release, in fact, Camel-kamelets is part of the dependency needed to release camel-k.
To me it doesn't makes sense to vote for this , because the kamelets could only be used in camel-k or on camel-kamelets main side. We are talking about a catalog more or less. It's not something consumable outside of a camel runtime. This has been discussed by the way in the past. In terms of ASF policy, it is possible to release multiple artifacts, if they are part of a release train. It looks like you're looking for finding problems where there aren't problems :-) Il ven 19 nov 2021, 22:53 David Jencks <david.a.jen...@gmail.com> ha scritto: > I’m uneasy about the use of the camel-kamelets subproject. AFAICT there > are no voted-on releases, and the website certainly only has a ‘next’ > version. > > According to my understanding of Apache policy this means that no one > other than camel developers should be using kamelets, and they certainly > shouldn’t be used in production. > > Furthermore, there seems to be a usage of kamelets by camel-k, > corresponding to a tag in camel-kamelets. I would expect a subproject > release to only depend on voted on and released versions of other > subprojects (as well, of course, released versions of other software). > > I would expect the cleanest solution would be to actually release > camel-kamelets after votes. We’d then be able to have non-prerelease > camel-kamelets documentation on the website and document the version links > between at least camel-k and camel-kamelets > > Otherwise, I’d like an explanation of how the current state of affairs is > consistent with Apache policy…. I’m no expert, but this situation seems > highly unusual to me. > > Thanks, > David Jencks
