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