By the way if you look at the vote for 1.7.0, but also for the old ones, camel-kamelets is listed under vote, like camel-k-runtime.
Search for [VOTE] Release Apache Camel K 1.7.0 and related libraries If we have 3 artifacts for make camel-k release with a 3 days time for vote, this means at least 5 days for each artifact to release, so for releasing a camel-k version, we should have at least 15 days of vote + release + alignment. This has no meaning and the artifacts don't have any sense outside of camel-k, so having separated votes doesn't make sense. Also, in 2021, 15 days for releasing a single artifact is frankly a joke. Il giorno ven 19 nov 2021 alle ore 23:06 Andrea Cosentino <anco...@gmail.com> ha scritto: > 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 > >
