Created. https://github.com/apache/camel-kamelets/tree/0.5.x
Il giorno lun 29 nov 2021 alle ore 06:23 Andrea Cosentino <anco...@gmail.com> ha scritto: > I think Nicola forgot to create the branch > > Il lun 29 nov 2021, 06:05 David Jencks <david.a.jen...@gmail.com> ha > scritto: > >> So I see version 0.5.0 in >> https://downloads.apache.org/camel/camel-kamelets/0.5.0/ but there’s no >> corresponding branch in GitHub, although there is a tag. Is this >> intentional? >> >> David Jencks >> >> > On Nov 19, 2021, at 3:03 PM, David Jencks <david.a.jen...@gmail.com> >> wrote: >> > >> > 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 >> >>> >> >>> >> > >> >>
