Kamelets releases???

[David Jencks <da...@gmail.com>]

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

Re: Kamelets releases???

[Andrea Cosentino <an...@gmail.com>]

Created.

https://github.com/apache/camel-kamelets/tree/0.5.x

Il giorno lun 29 nov 2021 alle ore 06:23 Andrea Cosentino <an...@gmail.com>
ha scritto:

> I think Nicola forgot to create the branch
>
> Il lun 29 nov 2021, 06:05 David Jencks <da...@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 <da...@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 <an...@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 <
>> ancosen@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 <da...@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
>> >>>
>> >>>
>> >
>>
>>

Re: Kamelets releases???

[Andrea Cosentino <an...@gmail.com>]

I think Nicola forgot to create the branch

Il lun 29 nov 2021, 06:05 David Jencks <da...@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 <da...@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 <an...@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 <
> ancosen@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 <da...@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
> >>>
> >>>
> >
>
>

Re: Kamelets releases???

[David Jencks <da...@gmail.com>]

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 <da...@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 <an...@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 <an...@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 <da...@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
>>> 
>>> 
> 

Re: Kamelets releases???

[David Jencks <da...@gmail.com>]

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 <an...@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 <an...@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 <da...@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
>> 
>> 

Re: Kamelets releases???

[Andrea Cosentino <an...@gmail.com>]

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 <an...@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 <da...@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
>
>

Re: Kamelets releases???

[Andrea Cosentino <an...@gmail.com>]

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 <da...@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