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 >>> >>> >
