I’m really glad to find out that camel-kamelets are voted on as part of the camel-k release. I’m happy for one vote to include any number of subprojects/artifacts.
If something gets voted on, then I think the voted-on artifacts should be listed on the downloads page in some form. I think this is a requirement of Apache policy. Since AFAICT they aren’t there, there are no release branches, and I didn’t think to look in the camel-k vote, I wondered if there were actual voted-on releases. I also think that if there are released versions of a subproject that should be reflected in the documentation. This can be dealt with using tags but it’s much more flexible to use release branches, and that would bring the project in line with every other camel subproject. If kamelets are effectively a part of camel-k, does it make sense to have a separate documentation component for them? camel-k-runtime docs are included under the camel-k docs without a separate component. We could easily do the same for kamelets. If that doesn’t make sense, does it make sense to align the versions? Thanks David Jencks > On Nov 19, 2021, at 2:14 PM, Andrea Cosentino <anco...@gmail.com> wrote: > > 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 >> >>