You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by David Jencks <da...@gmail.com> on 2022/01/15 05:37:14 UTC
comments on c-k-c docs state && RI preview
I noticed a few things working on the RI info for camel-kafka-connector.
- the compatibility matrices are thoroughly out of date, e.g. https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>
- All other camel subprojects use e.g. 2.5.x as the Antora component version, but c-k-c is using 0.11.0. Especially since it’s LTS I think we should change it to 0.11.x so when 0.11.1 comes out the version still makes sense, as well as being consistent with the rest of the site. I’m setting the 1.0.x branch up to say 1.0.x as the Antora version.
- archetype-dataformat-connector has camel-version 3.6.0, rather out of date.
- the maven versions in 1.0.x branch is 1.1.0-SNAPSHOT and for 0.11.x 0.12.0-SNAPSHOT. I think these should increment the micro version, not minor version?
- Is 1.0.x LTS?
- I guess it would make sense to change
Camel Kafka Connector allows you to use all Camel components <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html> as Kafka Connect <http://kafka.apache.org/documentation/#connect> connectors.
to
Camel Kafka Connector allows you to use all Kamelets as Kafka Connect <http://kafka.apache.org/documentation/#connect> connectors.
As part of the RI effort there’s a preview for c-k-c at https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html
David Jencks
Re: comments on c-k-c docs state && RI preview
Posted by Andrea <an...@tarocch.it>.
First of all thanks for the work!
On Wed, Jan 19, 2022, at 03:08, David Jencks wrote:
> Putting the conclusion at the top….
>
> https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>
Looks awesome!
>
> I put the compatibility table at the bottom of the index page, added a kamelets column, and turned entries into links where plausible.
>
> The table is also on the compatibility matrix page.
>
> If the index page looks good, I’ll remove the compatibility page and squash everything.
Good for me!
>
> No one has commented on whether such a table would be useful or desirable for other camel subprojects.
>
> David Jencks
>
> > On Jan 18, 2022, at 6:19 AM, Andrea <an...@tarocch.it> wrote:
> >
> >
> >
> > On Tue, Jan 18, 2022, at 05:55, David Jencks wrote:
> >>
> >>
> >>> On Jan 17, 2022, at 1:50 PM, Andrea <an...@tarocch.it> wrote:
> >>>
> >>>
> >>>
> >>> On Mon, Jan 17, 2022, at 18:00, David Jencks wrote:
> >>>>
> >>>>
> >>>>> On Jan 17, 2022, at 3:23 AM, Andrea <andrea@tarocch.it <ma...@tarocch.it>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Jan 17, 2022, at 07:24, David Jencks wrote:
> >>>>>> Thanks, inline...
> >>>>>>
> >>>>>>> On Jan 16, 2022, at 1:04 AM, Andrea <andrea@tarocch.it <ma...@tarocch.it>> wrote:
> >>>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> comments inline:
> >>>>>>>
> >>>>>>> On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
> >>>>>>>> I noticed a few things working on the RI info for camel-kafka-connector.
> >>>>>>>>
> >>>>>>>> - the compatibility matrices are thoroughly out of date, e.g. https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html> <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>>
> >>>
> >>> Awesome, basically a collection of the content of all these notes
> >>> <image.png>
> >>> could be the generated compatibility matrix page? Or is there already a way where that content is sown other that for the last release?
> >>
> >> Here’s a basic generated table for the compatibility matrix: https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/user-guide/camel-compatibility-matrix.html
> >>
> >> Note:
> >> - it will only ever have one line per branch: there’s no way to have separate lines for e.g. 0.11.0, 0.11.1. 0.11.2, etc, since there is only one doc version that covers all of these.
> >
> > well in case it is needed we can always do a version from a tag
> >> - It only has currently documented versions listed. This makes it self-maintaining: adding anything else will require periodic manual updates, which will gradually decay into wrong or outdated information.
> >>
> >> Are these acceptable limitations?
> >
> > fine for me
> >>
> >> - This version of the table isn’t quite finished: for instance the “branch” for next is wrong. If we like this generated table in principle, I can fix that and turn most entries into links.
> >
> > can you also add the version of the kamelet catalog?
> >>
> >> However, I’m not entirely sure that having this information duplicated/aggregated from the index pages is useful. I think we should just delete the compatibility matrix page. WDYT?
> >
> > as long as the table is somewhere I don't particularly care; it is fine to put it in the index page and remove the compatibility matrix page
> >>
> >> On the other hand, if this table is popular, maybe we should have one for each subproject.
> >>
> >> David Jencks
> >>
> >>>
> >>>
> >>>>>>> Yep the compatibility matrix page needs some love... a column mentioning kamelet catalog version needs to be added and probably we can remove some old rows?
> >>>>>>> willing to help on this on too? :)
> >>>>>>
> >>>>>> I think the entire existing matrix is out of date and should be removed? Or are there usable versions of c-k-c that aren’t documented?
> >>>>>>
> >>>>>> I wonder if the RI information is sufficient, WDYT?
> >>>>>
> >>>>> Where can I see a preview of the site with the IR information?
> >>>>
> >>>> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html> <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html>> shows all three branches (including not-quite-released 1.0).
> >>>>
> >>>>>>
> >>>>>> If you’re sure we need the matrix, let me know where it should start and I’ll make some PRs. I’d suggest having only one copy, perhaps in next, and referring to it from the other branches.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> - All other camel subprojects use e.g. 2.5.x as the Antora component version, but c-k-c is using 0.11.0. Especially since it’s LTS I think we should change it to 0.11.x so when 0.11.1 comes out the version still makes sense, as well as being consistent with the rest of the site. I’m setting the 1.0.x branch up to say 1.0.x as the Antora version.
> >>>>>>> +1 I agree
> >>>>>>>
> >>>>>>
> >>>>>> I’ve changed to 0.11.x in my RI PR.
> >>>>>>
> >>>>>>>>
> >>>>>>>> - archetype-dataformat-connector has camel-version 3.6.0, rather out of date.
> >>>>>>> What do you mean here?
> >>>>>>
> >>>>>> I should have looked harder and explained better. The example output shown in archetype-dataformat-connector.adoc shows using camel 3.6.0. This page should probably be updated, and I wonder if it is even relevant for the kamelet-based c-k-c.
> >>>>>
> >>>>> Yep for sure that part needs to be revisited and re-evaluated...
> >>>>>>>
> >>>>>>>>
> >>>>>>>> - the maven versions in 1.0.x branch is 1.1.0-SNAPSHOT and for 0.11.x 0.12.0-SNAPSHOT. I think these should increment the micro version, not minor version?
> >>>>>>> In theory you are right, in practice for convenience and based on how maven release plugin works and how we do releases, is more convenient to leave the version set as next release version even in the single releases branches... hoping to remember that once a new minor release of a release branch is needed.
> >>>>>>>
> >>>>>>> I admit that might be we are just being lazy and there is a reasonably hassle free way of handling this better?
> >>>>>>
> >>>>>> Perhaps I didn’t explain very well. Both 0.11.0 and 1.0.0 are LTS so we can expect releases on these branches. The next versions will be 0.11.1 and 1.0.1, so the current maven versions should be 0.11.1-SNAPSHOT and 1.0.1-SNAPSHOT, with the micro version incremented: the current 0.12.0-SNAPSHOT and 1.1.0-SNAPSHOT are extremely misleading.
> >>>>>
> >>>>> I understand that is misleading, but at the same time it is convenient from a release pov, because we mass change the version only during release and it is set to the next "major" release that will happen from main branch... doing what you suggest would require to add some steps to the already long and tedious release process... I am not sure it is worth the effort but I admit I am biased being the one who does the releases 90% of the times :)
> >>>>
> >>>> It’s been years since I did a release, and I’m not sure the maven tools have gotten much better. However, I think the other camel subprojects have found a way to have the branch maven versions more correct. I think that “LTS” means to expect more releases on the branch, and changing the branch version from 0.12.0-SNAPSHOT to 0.11.1-SNAPSHOT before release seems extremely awkward to me.
> >>>
> >>> I will look into what other sub projects does thanks
> >>>> Thanks!
> >>>>
> >>>> David Jencks
> >>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> - Is 1.0.x LTS?
> >>>>>>> Yes it is, as it is 0.11.0
> >>>>>>
> >>>>>> I changed to this in my RI PR.
> >>>>>>
> >>>>>>>>
> >>>>>>>> - I guess it would make sense to change
> >>>>>>>>
> >>>>>>>> Camel Kafka Connector allows you to use all Camel components <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html>> as Kafka Connect <http://kafka.apache.org/documentation/#connect <http://kafka.apache.org/documentation/#connect>> connectors.
> >>>>>>>> to
> >>>>>>>> Camel Kafka Connector allows you to use all Kamelets as Kafka Connect <http://kafka.apache.org/documentation/#connect <http://kafka.apache.org/documentation/#connect>> connectors.*
> >>>>>>> +1 I agree
> >>>>>>
> >>>>>> Lets do that in another PR :-).
> >>>>>>>
> >>>>>>>>
> >>>>>>>> As part of the RI effort there’s a preview for c-k-c at https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>
> >>>>>>>>
> >>>>>>>> David Jencks
> >>>>>>
> >>>>>> The RI PRs are merged and the next and 0,11.x should be visible shortly.
> >>>>>>
> >>>>>> Thanks
> >>>>>> David Jencks
> >>
> >>
>
>
Re: comments on c-k-c docs state && RI preview
Posted by David Jencks <da...@gmail.com>.
There’s the preview PR which shouldn’t be merged because it refers to all my repos, but there’s also https://github.com/apache/camel-website/pull/763 <https://github.com/apache/camel-website/pull/763> which does need to be merged but I haven’t been able to attract anyone’s attention to it. That will bring in the contents to all these new tables plus the newly released camel-k/kamelets branches.
David Jencks
> On Jan 24, 2022, at 4:36 PM, Andrea <an...@tarocch.it> wrote:
>
> Hello,
>
> On Sun, Jan 23, 2022, at 07:18, David Jencks wrote:
>> With 18 PRs, there are compatibility tables for everything except camel base, camel-karaf, and camel-spring boot: see preview at e.g. https://pr-747--camel.netlify.app/camel-quarkus/next/index.html#_compatibility_matrix <https://pr-747--camel.netlify.app/camel-quarkus/next/index.html#_compatibility_matrix> <https://pr-747--camel.netlify.app/camel-quarkus/next/index.html#_compatibility_matrix <https://pr-747--camel.netlify.app/camel-quarkus/next/index.html#_compatibility_matrix>>.
>
> Thanks for the work! Preview looks awesome!
>
> Published site have some issues though?
>
> <image.png>
> the PR of the preview is marked as don' merge, what is holding us off?
>
>>
>> These PRs also add the branches for camel-k 1.8.x,camel-k-runtime 1.11.x, and kamelets 0.7.x releases, I expect the vote can be concluded at any time.
>>
>> I think many of the PR builds are failing: the few I’ve looked at appear to be for reasons unrelated to these PRs. If these PRs cause actual problems I’m happy to fix them but it would be great if others could determine whether they cause problems.
>>
>> I think it would be a good idea to eventually add this info for the remaining projects, but I’m planning to take a break and work on something more interesting for a while, such as generating camel-quarkus pages.
>>
>> David Jencks
>>
>> > On Jan 18, 2022, at 10:29 PM, Andrea Cosentino <ancosen@gmail.com <ma...@gmail.com>> wrote:
>> >
>> > I think it would be really great to have it for camel-k and all the other
>> > subprojects.
>> >
>> > Il giorno mer 19 gen 2022 alle ore 07:27 Claus Ibsen <claus.ibsen@gmail.com <ma...@gmail.com>>
>> > ha scritto:
>> >
>> >> On Wed, Jan 19, 2022 at 3:08 AM David Jencks <david.a.jencks@gmail.com <ma...@gmail.com>>
>> >> wrote:
>> >>>
>> >>> Putting the conclusion at the top….
>> >>>
>> >>> https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>
>> >> <https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>>
>> >>>
>> >>> I put the compatibility table at the bottom of the index page, added a
>> >> kamelets column, and turned entries into links where plausible.
>> >>>
>> >>> The table is also on the compatibility matrix page.
>> >>>
>> >>> If the index page looks good, I’ll remove the compatibility page and
>> >> squash everything.
>> >>>
>> >>> No one has commented on whether such a table would be useful or
>> >> desirable for other camel subprojects.
>> >>>
>> >>
>> >> Whoa that matrix looks really good.
>> >>
>> >> Yes I think its a good idea for other sub projects to have this page too.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>> David Jencks
>> >>>
>> >>>> On Jan 18, 2022, at 6:19 AM, Andrea <andrea@tarocch.it <ma...@tarocch.it>> wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Tue, Jan 18, 2022, at 05:55, David Jencks wrote:
>> >>>>>
>> >>>>>
>> >>>>>> On Jan 17, 2022, at 1:50 PM, Andrea <andrea@tarocch.it <ma...@tarocch.it>> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Mon, Jan 17, 2022, at 18:00, David Jencks wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> On Jan 17, 2022, at 3:23 AM, Andrea <andrea@tarocch.it <ma...@tarocch.it> <mailto:
>> >> andrea@tarocch.it <ma...@tarocch.it>>> wrote:
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On Mon, Jan 17, 2022, at 07:24, David Jencks wrote:
>> >>>>>>>>> Thanks, inline...
>> >>>>>>>>>
>> >>>>>>>>>> On Jan 16, 2022, at 1:04 AM, Andrea <andrea@tarocch.it <ma...@tarocch.it> <mailto:
>> >> andrea@tarocch.it <ma...@tarocch.it>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> Hello,
>> >>>>>>>>>>
>> >>>>>>>>>> comments inline:
>> >>>>>>>>>>
>> >>>>>>>>>> On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
>> >>>>>>>>>>> I noticed a few things working on the RI info for
>> >> camel-kafka-connector.
>> >>>>>>>>>>>
>> >>>>>>>>>>> - the compatibility matrices are thoroughly out of date, e.g.
>> >> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>
>> >> <
>> >> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>>
>> >> <
>> >> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>
>> >> <
>> >> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>
>> >>>>
>> >>>>>>
>> >>>>>> Awesome, basically a collection of the content of all these notes
>> >>>>>> <image.png>
>> >>>>>> could be the generated compatibility matrix page? Or is there
>> >> already a way where that content is sown other that for the last release?
>> >>>>>
>> >>>>> Here’s a basic generated table for the compatibility matrix:
>> >> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/user-guide/camel-compatibility-matrix.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/user-guide/camel-compatibility-matrix.html>
>> >>>>>
>> >>>>> Note:
>> >>>>> - it will only ever have one line per branch: there’s no way to have
>> >> separate lines for e.g. 0.11.0, 0.11.1. 0.11.2, etc, since there is only
>> >> one doc version that covers all of these.
>> >>>>
>> >>>> well in case it is needed we can always do a version from a tag
>> >>>>> - It only has currently documented versions listed. This makes it
>> >> self-maintaining: adding anything else will require periodic manual
>> >> updates, which will gradually decay into wrong or outdated information.
>> >>>>>
>> >>>>> Are these acceptable limitations?
>> >>>>
>> >>>> fine for me
>> >>>>>
>> >>>>> - This version of the table isn’t quite finished: for instance the
>> >> “branch” for next is wrong. If we like this generated table in principle,
>> >> I can fix that and turn most entries into links.
>> >>>>
>> >>>> can you also add the version of the kamelet catalog?
>> >>>>>
>> >>>>> However, I’m not entirely sure that having this information
>> >> duplicated/aggregated from the index pages is useful. I think we should
>> >> just delete the compatibility matrix page. WDYT?
>> >>>>
>> >>>> as long as the table is somewhere I don't particularly care; it is
>> >> fine to put it in the index page and remove the compatibility matrix page
>> >>>>>
>> >>>>> On the other hand, if this table is popular, maybe we should have one
>> >> for each subproject.
>> >>>>>
>> >>>>> David Jencks
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>>>>> Yep the compatibility matrix page needs some love... a column
>> >> mentioning kamelet catalog version needs to be added and probably we can
>> >> remove some old rows?
>> >>>>>>>>>> willing to help on this on too? :)
>> >>>>>>>>>
>> >>>>>>>>> I think the entire existing matrix is out of date and should be
>> >> removed? Or are there usable versions of c-k-c that aren’t documented?
>> >>>>>>>>>
>> >>>>>>>>> I wonder if the RI information is sufficient, WDYT?
>> >>>>>>>>
>> >>>>>>>> Where can I see a preview of the site with the IR information?
>> >>>>>>>
>> >>>>>>>
>> >> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html> <
>> >> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html>>
>> >> <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html>
>> >> <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html>>>
>> >> shows all three branches (including not-quite-released 1.0).
>> >>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> If you’re sure we need the matrix, let me know where it should
>> >> start and I’ll make some PRs. I’d suggest having only one copy, perhaps in
>> >> next, and referring to it from the other branches.
>> >>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> - All other camel subprojects use e.g. 2.5.x as the Antora
>> >> component version, but c-k-c is using 0.11.0. Especially since it’s LTS I
>> >> think we should change it to 0.11.x so when 0.11.1 comes out the version
>> >> still makes sense, as well as being consistent with the rest of the site.
>> >> I’m setting the 1.0.x branch up to say 1.0.x as the Antora version.
>> >>>>>>>>>> +1 I agree
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> I’ve changed to 0.11.x in my RI PR.
>> >>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> - archetype-dataformat-connector has camel-version 3.6.0,
>> >> rather out of date.
>> >>>>>>>>>> What do you mean here?
>> >>>>>>>>>
>> >>>>>>>>> I should have looked harder and explained better. The example
>> >> output shown in archetype-dataformat-connector.adoc shows using camel
>> >> 3.6.0. This page should probably be updated, and I wonder if it is even
>> >> relevant for the kamelet-based c-k-c.
>> >>>>>>>>
>> >>>>>>>> Yep for sure that part needs to be revisited and re-evaluated...
>> >>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> - the maven versions in 1.0.x branch is 1.1.0-SNAPSHOT and for
>> >> 0.11.x 0.12.0-SNAPSHOT. I think these should increment the micro version,
>> >> not minor version?
>> >>>>>>>>>> In theory you are right, in practice for convenience and based
>> >> on how maven release plugin works and how we do releases, is more
>> >> convenient to leave the version set as next release version even in the
>> >> single releases branches... hoping to remember that once a new minor
>> >> release of a release branch is needed.
>> >>>>>>>>>>
>> >>>>>>>>>> I admit that might be we are just being lazy and there is a
>> >> reasonably hassle free way of handling this better?
>> >>>>>>>>>
>> >>>>>>>>> Perhaps I didn’t explain very well. Both 0.11.0 and 1.0.0 are
>> >> LTS so we can expect releases on these branches. The next versions will be
>> >> 0.11.1 and 1.0.1, so the current maven versions should be 0.11.1-SNAPSHOT
>> >> and 1.0.1-SNAPSHOT, with the micro version incremented: the current
>> >> 0.12.0-SNAPSHOT and 1.1.0-SNAPSHOT are extremely misleading.
>> >>>>>>>>
>> >>>>>>>> I understand that is misleading, but at the same time it is
>> >> convenient from a release pov, because we mass change the version only
>> >> during release and it is set to the next "major" release that will happen
>> >> from main branch... doing what you suggest would require to add some steps
>> >> to the already long and tedious release process... I am not sure it is
>> >> worth the effort but I admit I am biased being the one who does the
>> >> releases 90% of the times :)
>> >>>>>>>
>> >>>>>>> It’s been years since I did a release, and I’m not sure the maven
>> >> tools have gotten much better. However, I think the other camel
>> >> subprojects have found a way to have the branch maven versions more
>> >> correct. I think that “LTS” means to expect more releases on the branch,
>> >> and changing the branch version from 0.12.0-SNAPSHOT to 0.11.1-SNAPSHOT
>> >> before release seems extremely awkward to me.
>> >>>>>>
>> >>>>>> I will look into what other sub projects does thanks
>> >>>>>>> Thanks!
>> >>>>>>>
>> >>>>>>> David Jencks
>> >>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> - Is 1.0.x LTS?
>> >>>>>>>>>> Yes it is, as it is 0.11.0
>> >>>>>>>>>
>> >>>>>>>>> I changed to this in my RI PR.
>> >>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> - I guess it would make sense to change
>> >>>>>>>>>>>
>> >>>>>>>>>>> Camel Kafka Connector allows you to use all Camel components
>> >> <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html>
>> >> <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html>>>
>> >> as Kafka Connect <http://kafka.apache.org/documentation/#connect <http://kafka.apache.org/documentation/#connect> <
>> >> http://kafka.apache.org/documentation/#connect <http://kafka.apache.org/documentation/#connect>>> connectors.
>> >>>>>>>>>>> to
>> >>>>>>>>>>> Camel Kafka Connector allows you to use all Kamelets as Kafka
>> >> Connect <http://kafka.apache.org/documentation/#connect <http://kafka.apache.org/documentation/#connect> <
>> >> http://kafka.apache.org/documentation/#connect <http://kafka.apache.org/documentation/#connect>>> connectors.*
>> >>>>>>>>>> +1 I agree
>> >>>>>>>>>
>> >>>>>>>>> Lets do that in another PR :-).
>> >>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> As part of the RI effort there’s a preview for c-k-c at
>> >> https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html> <
>> >> https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> David Jencks
>> >>>>>>>>>
>> >>>>>>>>> The RI PRs are merged and the next and 0,11.x should be visible
>> >> shortly.
>> >>>>>>>>>
>> >>>>>>>>> Thanks
>> >>>>>>>>> David Jencks
>> >>>>>
>> >>>>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Claus Ibsen
>> >> -----------------
>> >> http://davsclaus.com <http://davsclaus.com/> @davsclaus
>> >> Camel in Action 2: https://www.manning.com/ibsen2 <https://www.manning.com/ibsen2>
>> >>
Re: comments on c-k-c docs state && RI preview
Posted by Andrea <an...@tarocch.it>.
Hello,
On Sun, Jan 23, 2022, at 07:18, David Jencks wrote:
> With 18 PRs, there are compatibility tables for everything except camel base, camel-karaf, and camel-spring boot: see preview at e.g. https://pr-747--camel.netlify.app/camel-quarkus/next/index.html#_compatibility_matrix <https://pr-747--camel.netlify.app/camel-quarkus/next/index.html#_compatibility_matrix>.
Thanks for the work! Preview looks awesome!
Published site have some issues though?
the PR of the preview is marked as don' merge, what is holding us off?
>
> These PRs also add the branches for camel-k 1.8.x,camel-k-runtime 1.11.x, and kamelets 0.7.x releases, I expect the vote can be concluded at any time.
>
> I think many of the PR builds are failing: the few I’ve looked at appear to be for reasons unrelated to these PRs. If these PRs cause actual problems I’m happy to fix them but it would be great if others could determine whether they cause problems.
>
> I think it would be a good idea to eventually add this info for the remaining projects, but I’m planning to take a break and work on something more interesting for a while, such as generating camel-quarkus pages.
>
> David Jencks
>
> > On Jan 18, 2022, at 10:29 PM, Andrea Cosentino <an...@gmail.com> wrote:
> >
> > I think it would be really great to have it for camel-k and all the other
> > subprojects.
> >
> > Il giorno mer 19 gen 2022 alle ore 07:27 Claus Ibsen <cl...@gmail.com>
> > ha scritto:
> >
> >> On Wed, Jan 19, 2022 at 3:08 AM David Jencks <da...@gmail.com>
> >> wrote:
> >>>
> >>> Putting the conclusion at the top….
> >>>
> >>> https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html
> >> <https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>
> >>>
> >>> I put the compatibility table at the bottom of the index page, added a
> >> kamelets column, and turned entries into links where plausible.
> >>>
> >>> The table is also on the compatibility matrix page.
> >>>
> >>> If the index page looks good, I’ll remove the compatibility page and
> >> squash everything.
> >>>
> >>> No one has commented on whether such a table would be useful or
> >> desirable for other camel subprojects.
> >>>
> >>
> >> Whoa that matrix looks really good.
> >>
> >> Yes I think its a good idea for other sub projects to have this page too.
> >>
> >>
> >>
> >>
> >>
> >>> David Jencks
> >>>
> >>>> On Jan 18, 2022, at 6:19 AM, Andrea <an...@tarocch.it> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Jan 18, 2022, at 05:55, David Jencks wrote:
> >>>>>
> >>>>>
> >>>>>> On Jan 17, 2022, at 1:50 PM, Andrea <an...@tarocch.it> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Jan 17, 2022, at 18:00, David Jencks wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Jan 17, 2022, at 3:23 AM, Andrea <andrea@tarocch.it <mailto:
> >> andrea@tarocch.it>> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Mon, Jan 17, 2022, at 07:24, David Jencks wrote:
> >>>>>>>>> Thanks, inline...
> >>>>>>>>>
> >>>>>>>>>> On Jan 16, 2022, at 1:04 AM, Andrea <andrea@tarocch.it <mailto:
> >> andrea@tarocch.it>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hello,
> >>>>>>>>>>
> >>>>>>>>>> comments inline:
> >>>>>>>>>>
> >>>>>>>>>> On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
> >>>>>>>>>>> I noticed a few things working on the RI info for
> >> camel-kafka-connector.
> >>>>>>>>>>>
> >>>>>>>>>>> - the compatibility matrices are thoroughly out of date, e.g.
> >> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html
> >> <
> >> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>
> >> <
> >> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html
> >> <
> >> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html
> >>>>
> >>>>>>
> >>>>>> Awesome, basically a collection of the content of all these notes
> >>>>>> <image.png>
> >>>>>> could be the generated compatibility matrix page? Or is there
> >> already a way where that content is sown other that for the last release?
> >>>>>
> >>>>> Here’s a basic generated table for the compatibility matrix:
> >> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/user-guide/camel-compatibility-matrix.html
> >>>>>
> >>>>> Note:
> >>>>> - it will only ever have one line per branch: there’s no way to have
> >> separate lines for e.g. 0.11.0, 0.11.1. 0.11.2, etc, since there is only
> >> one doc version that covers all of these.
> >>>>
> >>>> well in case it is needed we can always do a version from a tag
> >>>>> - It only has currently documented versions listed. This makes it
> >> self-maintaining: adding anything else will require periodic manual
> >> updates, which will gradually decay into wrong or outdated information.
> >>>>>
> >>>>> Are these acceptable limitations?
> >>>>
> >>>> fine for me
> >>>>>
> >>>>> - This version of the table isn’t quite finished: for instance the
> >> “branch” for next is wrong. If we like this generated table in principle,
> >> I can fix that and turn most entries into links.
> >>>>
> >>>> can you also add the version of the kamelet catalog?
> >>>>>
> >>>>> However, I’m not entirely sure that having this information
> >> duplicated/aggregated from the index pages is useful. I think we should
> >> just delete the compatibility matrix page. WDYT?
> >>>>
> >>>> as long as the table is somewhere I don't particularly care; it is
> >> fine to put it in the index page and remove the compatibility matrix page
> >>>>>
> >>>>> On the other hand, if this table is popular, maybe we should have one
> >> for each subproject.
> >>>>>
> >>>>> David Jencks
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>>> Yep the compatibility matrix page needs some love... a column
> >> mentioning kamelet catalog version needs to be added and probably we can
> >> remove some old rows?
> >>>>>>>>>> willing to help on this on too? :)
> >>>>>>>>>
> >>>>>>>>> I think the entire existing matrix is out of date and should be
> >> removed? Or are there usable versions of c-k-c that aren’t documented?
> >>>>>>>>>
> >>>>>>>>> I wonder if the RI information is sufficient, WDYT?
> >>>>>>>>
> >>>>>>>> Where can I see a preview of the site with the IR information?
> >>>>>>>
> >>>>>>>
> >> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <
> >> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html>
> >> <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html
> >> <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html>>
> >> shows all three branches (including not-quite-released 1.0).
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>> If you’re sure we need the matrix, let me know where it should
> >> start and I’ll make some PRs. I’d suggest having only one copy, perhaps in
> >> next, and referring to it from the other branches.
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> - All other camel subprojects use e.g. 2.5.x as the Antora
> >> component version, but c-k-c is using 0.11.0. Especially since it’s LTS I
> >> think we should change it to 0.11.x so when 0.11.1 comes out the version
> >> still makes sense, as well as being consistent with the rest of the site.
> >> I’m setting the 1.0.x branch up to say 1.0.x as the Antora version.
> >>>>>>>>>> +1 I agree
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I’ve changed to 0.11.x in my RI PR.
> >>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> - archetype-dataformat-connector has camel-version 3.6.0,
> >> rather out of date.
> >>>>>>>>>> What do you mean here?
> >>>>>>>>>
> >>>>>>>>> I should have looked harder and explained better. The example
> >> output shown in archetype-dataformat-connector.adoc shows using camel
> >> 3.6.0. This page should probably be updated, and I wonder if it is even
> >> relevant for the kamelet-based c-k-c.
> >>>>>>>>
> >>>>>>>> Yep for sure that part needs to be revisited and re-evaluated...
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> - the maven versions in 1.0.x branch is 1.1.0-SNAPSHOT and for
> >> 0.11.x 0.12.0-SNAPSHOT. I think these should increment the micro version,
> >> not minor version?
> >>>>>>>>>> In theory you are right, in practice for convenience and based
> >> on how maven release plugin works and how we do releases, is more
> >> convenient to leave the version set as next release version even in the
> >> single releases branches... hoping to remember that once a new minor
> >> release of a release branch is needed.
> >>>>>>>>>>
> >>>>>>>>>> I admit that might be we are just being lazy and there is a
> >> reasonably hassle free way of handling this better?
> >>>>>>>>>
> >>>>>>>>> Perhaps I didn’t explain very well. Both 0.11.0 and 1.0.0 are
> >> LTS so we can expect releases on these branches. The next versions will be
> >> 0.11.1 and 1.0.1, so the current maven versions should be 0.11.1-SNAPSHOT
> >> and 1.0.1-SNAPSHOT, with the micro version incremented: the current
> >> 0.12.0-SNAPSHOT and 1.1.0-SNAPSHOT are extremely misleading.
> >>>>>>>>
> >>>>>>>> I understand that is misleading, but at the same time it is
> >> convenient from a release pov, because we mass change the version only
> >> during release and it is set to the next "major" release that will happen
> >> from main branch... doing what you suggest would require to add some steps
> >> to the already long and tedious release process... I am not sure it is
> >> worth the effort but I admit I am biased being the one who does the
> >> releases 90% of the times :)
> >>>>>>>
> >>>>>>> It’s been years since I did a release, and I’m not sure the maven
> >> tools have gotten much better. However, I think the other camel
> >> subprojects have found a way to have the branch maven versions more
> >> correct. I think that “LTS” means to expect more releases on the branch,
> >> and changing the branch version from 0.12.0-SNAPSHOT to 0.11.1-SNAPSHOT
> >> before release seems extremely awkward to me.
> >>>>>>
> >>>>>> I will look into what other sub projects does thanks
> >>>>>>> Thanks!
> >>>>>>>
> >>>>>>> David Jencks
> >>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> - Is 1.0.x LTS?
> >>>>>>>>>> Yes it is, as it is 0.11.0
> >>>>>>>>>
> >>>>>>>>> I changed to this in my RI PR.
> >>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> - I guess it would make sense to change
> >>>>>>>>>>>
> >>>>>>>>>>> Camel Kafka Connector allows you to use all Camel components
> >> <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html
> >> <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html>>
> >> as Kafka Connect <http://kafka.apache.org/documentation/#connect <
> >> http://kafka.apache.org/documentation/#connect>> connectors.
> >>>>>>>>>>> to
> >>>>>>>>>>> Camel Kafka Connector allows you to use all Kamelets as Kafka
> >> Connect <http://kafka.apache.org/documentation/#connect <
> >> http://kafka.apache.org/documentation/#connect>> connectors.*
> >>>>>>>>>> +1 I agree
> >>>>>>>>>
> >>>>>>>>> Lets do that in another PR :-).
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> As part of the RI effort there’s a preview for c-k-c at
> >> https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html <
> >> https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>
> >>>>>>>>>>>
> >>>>>>>>>>> David Jencks
> >>>>>>>>>
> >>>>>>>>> The RI PRs are merged and the next and 0,11.x should be visible
> >> shortly.
> >>>>>>>>>
> >>>>>>>>> Thanks
> >>>>>>>>> David Jencks
> >>>>>
> >>>>>
> >>>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -----------------
> >> http://davsclaus.com @davsclaus
> >> Camel in Action 2: https://www.manning.com/ibsen2
> >>
>
>
Re: comments on c-k-c docs state && RI preview
Posted by David Jencks <da...@gmail.com>.
With 18 PRs, there are compatibility tables for everything except camel base, camel-karaf, and camel-spring boot: see preview at e.g. https://pr-747--camel.netlify.app/camel-quarkus/next/index.html#_compatibility_matrix <https://pr-747--camel.netlify.app/camel-quarkus/next/index.html#_compatibility_matrix>.
These PRs also add the branches for camel-k 1.8.x,camel-k-runtime 1.11.x, and kamelets 0.7.x releases, I expect the vote can be concluded at any time.
I think many of the PR builds are failing: the few I’ve looked at appear to be for reasons unrelated to these PRs. If these PRs cause actual problems I’m happy to fix them but it would be great if others could determine whether they cause problems.
I think it would be a good idea to eventually add this info for the remaining projects, but I’m planning to take a break and work on something more interesting for a while, such as generating camel-quarkus pages.
David Jencks
> On Jan 18, 2022, at 10:29 PM, Andrea Cosentino <an...@gmail.com> wrote:
>
> I think it would be really great to have it for camel-k and all the other
> subprojects.
>
> Il giorno mer 19 gen 2022 alle ore 07:27 Claus Ibsen <cl...@gmail.com>
> ha scritto:
>
>> On Wed, Jan 19, 2022 at 3:08 AM David Jencks <da...@gmail.com>
>> wrote:
>>>
>>> Putting the conclusion at the top….
>>>
>>> https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html
>> <https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>
>>>
>>> I put the compatibility table at the bottom of the index page, added a
>> kamelets column, and turned entries into links where plausible.
>>>
>>> The table is also on the compatibility matrix page.
>>>
>>> If the index page looks good, I’ll remove the compatibility page and
>> squash everything.
>>>
>>> No one has commented on whether such a table would be useful or
>> desirable for other camel subprojects.
>>>
>>
>> Whoa that matrix looks really good.
>>
>> Yes I think its a good idea for other sub projects to have this page too.
>>
>>
>>
>>
>>
>>> David Jencks
>>>
>>>> On Jan 18, 2022, at 6:19 AM, Andrea <an...@tarocch.it> wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Jan 18, 2022, at 05:55, David Jencks wrote:
>>>>>
>>>>>
>>>>>> On Jan 17, 2022, at 1:50 PM, Andrea <an...@tarocch.it> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 17, 2022, at 18:00, David Jencks wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Jan 17, 2022, at 3:23 AM, Andrea <andrea@tarocch.it <mailto:
>> andrea@tarocch.it>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jan 17, 2022, at 07:24, David Jencks wrote:
>>>>>>>>> Thanks, inline...
>>>>>>>>>
>>>>>>>>>> On Jan 16, 2022, at 1:04 AM, Andrea <andrea@tarocch.it <mailto:
>> andrea@tarocch.it>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> comments inline:
>>>>>>>>>>
>>>>>>>>>> On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
>>>>>>>>>>> I noticed a few things working on the RI info for
>> camel-kafka-connector.
>>>>>>>>>>>
>>>>>>>>>>> - the compatibility matrices are thoroughly out of date, e.g.
>> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html
>> <
>> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>
>> <
>> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html
>> <
>> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html
>>>>
>>>>>>
>>>>>> Awesome, basically a collection of the content of all these notes
>>>>>> <image.png>
>>>>>> could be the generated compatibility matrix page? Or is there
>> already a way where that content is sown other that for the last release?
>>>>>
>>>>> Here’s a basic generated table for the compatibility matrix:
>> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/user-guide/camel-compatibility-matrix.html
>>>>>
>>>>> Note:
>>>>> - it will only ever have one line per branch: there’s no way to have
>> separate lines for e.g. 0.11.0, 0.11.1. 0.11.2, etc, since there is only
>> one doc version that covers all of these.
>>>>
>>>> well in case it is needed we can always do a version from a tag
>>>>> - It only has currently documented versions listed. This makes it
>> self-maintaining: adding anything else will require periodic manual
>> updates, which will gradually decay into wrong or outdated information.
>>>>>
>>>>> Are these acceptable limitations?
>>>>
>>>> fine for me
>>>>>
>>>>> - This version of the table isn’t quite finished: for instance the
>> “branch” for next is wrong. If we like this generated table in principle,
>> I can fix that and turn most entries into links.
>>>>
>>>> can you also add the version of the kamelet catalog?
>>>>>
>>>>> However, I’m not entirely sure that having this information
>> duplicated/aggregated from the index pages is useful. I think we should
>> just delete the compatibility matrix page. WDYT?
>>>>
>>>> as long as the table is somewhere I don't particularly care; it is
>> fine to put it in the index page and remove the compatibility matrix page
>>>>>
>>>>> On the other hand, if this table is popular, maybe we should have one
>> for each subproject.
>>>>>
>>>>> David Jencks
>>>>>
>>>>>>
>>>>>>
>>>>>>>>>> Yep the compatibility matrix page needs some love... a column
>> mentioning kamelet catalog version needs to be added and probably we can
>> remove some old rows?
>>>>>>>>>> willing to help on this on too? :)
>>>>>>>>>
>>>>>>>>> I think the entire existing matrix is out of date and should be
>> removed? Or are there usable versions of c-k-c that aren’t documented?
>>>>>>>>>
>>>>>>>>> I wonder if the RI information is sufficient, WDYT?
>>>>>>>>
>>>>>>>> Where can I see a preview of the site with the IR information?
>>>>>>>
>>>>>>>
>> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <
>> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html>
>> <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html
>> <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html>>
>> shows all three branches (including not-quite-released 1.0).
>>>>>>>
>>>>>>>>>
>>>>>>>>> If you’re sure we need the matrix, let me know where it should
>> start and I’ll make some PRs. I’d suggest having only one copy, perhaps in
>> next, and referring to it from the other branches.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - All other camel subprojects use e.g. 2.5.x as the Antora
>> component version, but c-k-c is using 0.11.0. Especially since it’s LTS I
>> think we should change it to 0.11.x so when 0.11.1 comes out the version
>> still makes sense, as well as being consistent with the rest of the site.
>> I’m setting the 1.0.x branch up to say 1.0.x as the Antora version.
>>>>>>>>>> +1 I agree
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I’ve changed to 0.11.x in my RI PR.
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - archetype-dataformat-connector has camel-version 3.6.0,
>> rather out of date.
>>>>>>>>>> What do you mean here?
>>>>>>>>>
>>>>>>>>> I should have looked harder and explained better. The example
>> output shown in archetype-dataformat-connector.adoc shows using camel
>> 3.6.0. This page should probably be updated, and I wonder if it is even
>> relevant for the kamelet-based c-k-c.
>>>>>>>>
>>>>>>>> Yep for sure that part needs to be revisited and re-evaluated...
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - the maven versions in 1.0.x branch is 1.1.0-SNAPSHOT and for
>> 0.11.x 0.12.0-SNAPSHOT. I think these should increment the micro version,
>> not minor version?
>>>>>>>>>> In theory you are right, in practice for convenience and based
>> on how maven release plugin works and how we do releases, is more
>> convenient to leave the version set as next release version even in the
>> single releases branches... hoping to remember that once a new minor
>> release of a release branch is needed.
>>>>>>>>>>
>>>>>>>>>> I admit that might be we are just being lazy and there is a
>> reasonably hassle free way of handling this better?
>>>>>>>>>
>>>>>>>>> Perhaps I didn’t explain very well. Both 0.11.0 and 1.0.0 are
>> LTS so we can expect releases on these branches. The next versions will be
>> 0.11.1 and 1.0.1, so the current maven versions should be 0.11.1-SNAPSHOT
>> and 1.0.1-SNAPSHOT, with the micro version incremented: the current
>> 0.12.0-SNAPSHOT and 1.1.0-SNAPSHOT are extremely misleading.
>>>>>>>>
>>>>>>>> I understand that is misleading, but at the same time it is
>> convenient from a release pov, because we mass change the version only
>> during release and it is set to the next "major" release that will happen
>> from main branch... doing what you suggest would require to add some steps
>> to the already long and tedious release process... I am not sure it is
>> worth the effort but I admit I am biased being the one who does the
>> releases 90% of the times :)
>>>>>>>
>>>>>>> It’s been years since I did a release, and I’m not sure the maven
>> tools have gotten much better. However, I think the other camel
>> subprojects have found a way to have the branch maven versions more
>> correct. I think that “LTS” means to expect more releases on the branch,
>> and changing the branch version from 0.12.0-SNAPSHOT to 0.11.1-SNAPSHOT
>> before release seems extremely awkward to me.
>>>>>>
>>>>>> I will look into what other sub projects does thanks
>>>>>>> Thanks!
>>>>>>>
>>>>>>> David Jencks
>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - Is 1.0.x LTS?
>>>>>>>>>> Yes it is, as it is 0.11.0
>>>>>>>>>
>>>>>>>>> I changed to this in my RI PR.
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - I guess it would make sense to change
>>>>>>>>>>>
>>>>>>>>>>> Camel Kafka Connector allows you to use all Camel components
>> <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html
>> <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html>>
>> as Kafka Connect <http://kafka.apache.org/documentation/#connect <
>> http://kafka.apache.org/documentation/#connect>> connectors.
>>>>>>>>>>> to
>>>>>>>>>>> Camel Kafka Connector allows you to use all Kamelets as Kafka
>> Connect <http://kafka.apache.org/documentation/#connect <
>> http://kafka.apache.org/documentation/#connect>> connectors.*
>>>>>>>>>> +1 I agree
>>>>>>>>>
>>>>>>>>> Lets do that in another PR :-).
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> As part of the RI effort there’s a preview for c-k-c at
>> https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html <
>> https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>
>>>>>>>>>>>
>>>>>>>>>>> David Jencks
>>>>>>>>>
>>>>>>>>> The RI PRs are merged and the next and 0,11.x should be visible
>> shortly.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> David Jencks
>>>>>
>>>>>
>>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
Re: comments on c-k-c docs state && RI preview
Posted by Andrea Cosentino <an...@gmail.com>.
I think it would be really great to have it for camel-k and all the other
subprojects.
Il giorno mer 19 gen 2022 alle ore 07:27 Claus Ibsen <cl...@gmail.com>
ha scritto:
> On Wed, Jan 19, 2022 at 3:08 AM David Jencks <da...@gmail.com>
> wrote:
> >
> > Putting the conclusion at the top….
> >
> > https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html
> <https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>
> >
> > I put the compatibility table at the bottom of the index page, added a
> kamelets column, and turned entries into links where plausible.
> >
> > The table is also on the compatibility matrix page.
> >
> > If the index page looks good, I’ll remove the compatibility page and
> squash everything.
> >
> > No one has commented on whether such a table would be useful or
> desirable for other camel subprojects.
> >
>
> Whoa that matrix looks really good.
>
> Yes I think its a good idea for other sub projects to have this page too.
>
>
>
>
>
> > David Jencks
> >
> > > On Jan 18, 2022, at 6:19 AM, Andrea <an...@tarocch.it> wrote:
> > >
> > >
> > >
> > > On Tue, Jan 18, 2022, at 05:55, David Jencks wrote:
> > >>
> > >>
> > >>> On Jan 17, 2022, at 1:50 PM, Andrea <an...@tarocch.it> wrote:
> > >>>
> > >>>
> > >>>
> > >>> On Mon, Jan 17, 2022, at 18:00, David Jencks wrote:
> > >>>>
> > >>>>
> > >>>>> On Jan 17, 2022, at 3:23 AM, Andrea <andrea@tarocch.it <mailto:
> andrea@tarocch.it>> wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Mon, Jan 17, 2022, at 07:24, David Jencks wrote:
> > >>>>>> Thanks, inline...
> > >>>>>>
> > >>>>>>> On Jan 16, 2022, at 1:04 AM, Andrea <andrea@tarocch.it <mailto:
> andrea@tarocch.it>> wrote:
> > >>>>>>>
> > >>>>>>> Hello,
> > >>>>>>>
> > >>>>>>> comments inline:
> > >>>>>>>
> > >>>>>>> On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
> > >>>>>>>> I noticed a few things working on the RI info for
> camel-kafka-connector.
> > >>>>>>>>
> > >>>>>>>> - the compatibility matrices are thoroughly out of date, e.g.
> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html
> <
> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>
> <
> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html
> <
> https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html
> >>
> > >>>
> > >>> Awesome, basically a collection of the content of all these notes
> > >>> <image.png>
> > >>> could be the generated compatibility matrix page? Or is there
> already a way where that content is sown other that for the last release?
> > >>
> > >> Here’s a basic generated table for the compatibility matrix:
> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/user-guide/camel-compatibility-matrix.html
> > >>
> > >> Note:
> > >> - it will only ever have one line per branch: there’s no way to have
> separate lines for e.g. 0.11.0, 0.11.1. 0.11.2, etc, since there is only
> one doc version that covers all of these.
> > >
> > > well in case it is needed we can always do a version from a tag
> > >> - It only has currently documented versions listed. This makes it
> self-maintaining: adding anything else will require periodic manual
> updates, which will gradually decay into wrong or outdated information.
> > >>
> > >> Are these acceptable limitations?
> > >
> > > fine for me
> > >>
> > >> - This version of the table isn’t quite finished: for instance the
> “branch” for next is wrong. If we like this generated table in principle,
> I can fix that and turn most entries into links.
> > >
> > > can you also add the version of the kamelet catalog?
> > >>
> > >> However, I’m not entirely sure that having this information
> duplicated/aggregated from the index pages is useful. I think we should
> just delete the compatibility matrix page. WDYT?
> > >
> > > as long as the table is somewhere I don't particularly care; it is
> fine to put it in the index page and remove the compatibility matrix page
> > >>
> > >> On the other hand, if this table is popular, maybe we should have one
> for each subproject.
> > >>
> > >> David Jencks
> > >>
> > >>>
> > >>>
> > >>>>>>> Yep the compatibility matrix page needs some love... a column
> mentioning kamelet catalog version needs to be added and probably we can
> remove some old rows?
> > >>>>>>> willing to help on this on too? :)
> > >>>>>>
> > >>>>>> I think the entire existing matrix is out of date and should be
> removed? Or are there usable versions of c-k-c that aren’t documented?
> > >>>>>>
> > >>>>>> I wonder if the RI information is sufficient, WDYT?
> > >>>>>
> > >>>>> Where can I see a preview of the site with the IR information?
> > >>>>
> > >>>>
> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <
> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html>
> <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html
> <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html>>
> shows all three branches (including not-quite-released 1.0).
> > >>>>
> > >>>>>>
> > >>>>>> If you’re sure we need the matrix, let me know where it should
> start and I’ll make some PRs. I’d suggest having only one copy, perhaps in
> next, and referring to it from the other branches.
> > >>>>>>>
> > >>>>>>>>
> > >>>>>>>> - All other camel subprojects use e.g. 2.5.x as the Antora
> component version, but c-k-c is using 0.11.0. Especially since it’s LTS I
> think we should change it to 0.11.x so when 0.11.1 comes out the version
> still makes sense, as well as being consistent with the rest of the site.
> I’m setting the 1.0.x branch up to say 1.0.x as the Antora version.
> > >>>>>>> +1 I agree
> > >>>>>>>
> > >>>>>>
> > >>>>>> I’ve changed to 0.11.x in my RI PR.
> > >>>>>>
> > >>>>>>>>
> > >>>>>>>> - archetype-dataformat-connector has camel-version 3.6.0,
> rather out of date.
> > >>>>>>> What do you mean here?
> > >>>>>>
> > >>>>>> I should have looked harder and explained better. The example
> output shown in archetype-dataformat-connector.adoc shows using camel
> 3.6.0. This page should probably be updated, and I wonder if it is even
> relevant for the kamelet-based c-k-c.
> > >>>>>
> > >>>>> Yep for sure that part needs to be revisited and re-evaluated...
> > >>>>>>>
> > >>>>>>>>
> > >>>>>>>> - the maven versions in 1.0.x branch is 1.1.0-SNAPSHOT and for
> 0.11.x 0.12.0-SNAPSHOT. I think these should increment the micro version,
> not minor version?
> > >>>>>>> In theory you are right, in practice for convenience and based
> on how maven release plugin works and how we do releases, is more
> convenient to leave the version set as next release version even in the
> single releases branches... hoping to remember that once a new minor
> release of a release branch is needed.
> > >>>>>>>
> > >>>>>>> I admit that might be we are just being lazy and there is a
> reasonably hassle free way of handling this better?
> > >>>>>>
> > >>>>>> Perhaps I didn’t explain very well. Both 0.11.0 and 1.0.0 are
> LTS so we can expect releases on these branches. The next versions will be
> 0.11.1 and 1.0.1, so the current maven versions should be 0.11.1-SNAPSHOT
> and 1.0.1-SNAPSHOT, with the micro version incremented: the current
> 0.12.0-SNAPSHOT and 1.1.0-SNAPSHOT are extremely misleading.
> > >>>>>
> > >>>>> I understand that is misleading, but at the same time it is
> convenient from a release pov, because we mass change the version only
> during release and it is set to the next "major" release that will happen
> from main branch... doing what you suggest would require to add some steps
> to the already long and tedious release process... I am not sure it is
> worth the effort but I admit I am biased being the one who does the
> releases 90% of the times :)
> > >>>>
> > >>>> It’s been years since I did a release, and I’m not sure the maven
> tools have gotten much better. However, I think the other camel
> subprojects have found a way to have the branch maven versions more
> correct. I think that “LTS” means to expect more releases on the branch,
> and changing the branch version from 0.12.0-SNAPSHOT to 0.11.1-SNAPSHOT
> before release seems extremely awkward to me.
> > >>>
> > >>> I will look into what other sub projects does thanks
> > >>>> Thanks!
> > >>>>
> > >>>> David Jencks
> > >>>>
> > >>>>>>>
> > >>>>>>>>
> > >>>>>>>> - Is 1.0.x LTS?
> > >>>>>>> Yes it is, as it is 0.11.0
> > >>>>>>
> > >>>>>> I changed to this in my RI PR.
> > >>>>>>
> > >>>>>>>>
> > >>>>>>>> - I guess it would make sense to change
> > >>>>>>>>
> > >>>>>>>> Camel Kafka Connector allows you to use all Camel components
> <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html
> <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html>>
> as Kafka Connect <http://kafka.apache.org/documentation/#connect <
> http://kafka.apache.org/documentation/#connect>> connectors.
> > >>>>>>>> to
> > >>>>>>>> Camel Kafka Connector allows you to use all Kamelets as Kafka
> Connect <http://kafka.apache.org/documentation/#connect <
> http://kafka.apache.org/documentation/#connect>> connectors.*
> > >>>>>>> +1 I agree
> > >>>>>>
> > >>>>>> Lets do that in another PR :-).
> > >>>>>>>
> > >>>>>>>>
> > >>>>>>>> As part of the RI effort there’s a preview for c-k-c at
> https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html <
> https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>
> > >>>>>>>>
> > >>>>>>>> David Jencks
> > >>>>>>
> > >>>>>> The RI PRs are merged and the next and 0,11.x should be visible
> shortly.
> > >>>>>>
> > >>>>>> Thanks
> > >>>>>> David Jencks
> > >>
> > >>
> >
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
Re: comments on c-k-c docs state && RI preview
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Jan 19, 2022 at 3:08 AM David Jencks <da...@gmail.com> wrote:
>
> Putting the conclusion at the top….
>
> https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>
>
> I put the compatibility table at the bottom of the index page, added a kamelets column, and turned entries into links where plausible.
>
> The table is also on the compatibility matrix page.
>
> If the index page looks good, I’ll remove the compatibility page and squash everything.
>
> No one has commented on whether such a table would be useful or desirable for other camel subprojects.
>
Whoa that matrix looks really good.
Yes I think its a good idea for other sub projects to have this page too.
> David Jencks
>
> > On Jan 18, 2022, at 6:19 AM, Andrea <an...@tarocch.it> wrote:
> >
> >
> >
> > On Tue, Jan 18, 2022, at 05:55, David Jencks wrote:
> >>
> >>
> >>> On Jan 17, 2022, at 1:50 PM, Andrea <an...@tarocch.it> wrote:
> >>>
> >>>
> >>>
> >>> On Mon, Jan 17, 2022, at 18:00, David Jencks wrote:
> >>>>
> >>>>
> >>>>> On Jan 17, 2022, at 3:23 AM, Andrea <andrea@tarocch.it <ma...@tarocch.it>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Jan 17, 2022, at 07:24, David Jencks wrote:
> >>>>>> Thanks, inline...
> >>>>>>
> >>>>>>> On Jan 16, 2022, at 1:04 AM, Andrea <andrea@tarocch.it <ma...@tarocch.it>> wrote:
> >>>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> comments inline:
> >>>>>>>
> >>>>>>> On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
> >>>>>>>> I noticed a few things working on the RI info for camel-kafka-connector.
> >>>>>>>>
> >>>>>>>> - the compatibility matrices are thoroughly out of date, e.g. https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html> <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>>
> >>>
> >>> Awesome, basically a collection of the content of all these notes
> >>> <image.png>
> >>> could be the generated compatibility matrix page? Or is there already a way where that content is sown other that for the last release?
> >>
> >> Here’s a basic generated table for the compatibility matrix: https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/user-guide/camel-compatibility-matrix.html
> >>
> >> Note:
> >> - it will only ever have one line per branch: there’s no way to have separate lines for e.g. 0.11.0, 0.11.1. 0.11.2, etc, since there is only one doc version that covers all of these.
> >
> > well in case it is needed we can always do a version from a tag
> >> - It only has currently documented versions listed. This makes it self-maintaining: adding anything else will require periodic manual updates, which will gradually decay into wrong or outdated information.
> >>
> >> Are these acceptable limitations?
> >
> > fine for me
> >>
> >> - This version of the table isn’t quite finished: for instance the “branch” for next is wrong. If we like this generated table in principle, I can fix that and turn most entries into links.
> >
> > can you also add the version of the kamelet catalog?
> >>
> >> However, I’m not entirely sure that having this information duplicated/aggregated from the index pages is useful. I think we should just delete the compatibility matrix page. WDYT?
> >
> > as long as the table is somewhere I don't particularly care; it is fine to put it in the index page and remove the compatibility matrix page
> >>
> >> On the other hand, if this table is popular, maybe we should have one for each subproject.
> >>
> >> David Jencks
> >>
> >>>
> >>>
> >>>>>>> Yep the compatibility matrix page needs some love... a column mentioning kamelet catalog version needs to be added and probably we can remove some old rows?
> >>>>>>> willing to help on this on too? :)
> >>>>>>
> >>>>>> I think the entire existing matrix is out of date and should be removed? Or are there usable versions of c-k-c that aren’t documented?
> >>>>>>
> >>>>>> I wonder if the RI information is sufficient, WDYT?
> >>>>>
> >>>>> Where can I see a preview of the site with the IR information?
> >>>>
> >>>> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html> <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html>> shows all three branches (including not-quite-released 1.0).
> >>>>
> >>>>>>
> >>>>>> If you’re sure we need the matrix, let me know where it should start and I’ll make some PRs. I’d suggest having only one copy, perhaps in next, and referring to it from the other branches.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> - All other camel subprojects use e.g. 2.5.x as the Antora component version, but c-k-c is using 0.11.0. Especially since it’s LTS I think we should change it to 0.11.x so when 0.11.1 comes out the version still makes sense, as well as being consistent with the rest of the site. I’m setting the 1.0.x branch up to say 1.0.x as the Antora version.
> >>>>>>> +1 I agree
> >>>>>>>
> >>>>>>
> >>>>>> I’ve changed to 0.11.x in my RI PR.
> >>>>>>
> >>>>>>>>
> >>>>>>>> - archetype-dataformat-connector has camel-version 3.6.0, rather out of date.
> >>>>>>> What do you mean here?
> >>>>>>
> >>>>>> I should have looked harder and explained better. The example output shown in archetype-dataformat-connector.adoc shows using camel 3.6.0. This page should probably be updated, and I wonder if it is even relevant for the kamelet-based c-k-c.
> >>>>>
> >>>>> Yep for sure that part needs to be revisited and re-evaluated...
> >>>>>>>
> >>>>>>>>
> >>>>>>>> - the maven versions in 1.0.x branch is 1.1.0-SNAPSHOT and for 0.11.x 0.12.0-SNAPSHOT. I think these should increment the micro version, not minor version?
> >>>>>>> In theory you are right, in practice for convenience and based on how maven release plugin works and how we do releases, is more convenient to leave the version set as next release version even in the single releases branches... hoping to remember that once a new minor release of a release branch is needed.
> >>>>>>>
> >>>>>>> I admit that might be we are just being lazy and there is a reasonably hassle free way of handling this better?
> >>>>>>
> >>>>>> Perhaps I didn’t explain very well. Both 0.11.0 and 1.0.0 are LTS so we can expect releases on these branches. The next versions will be 0.11.1 and 1.0.1, so the current maven versions should be 0.11.1-SNAPSHOT and 1.0.1-SNAPSHOT, with the micro version incremented: the current 0.12.0-SNAPSHOT and 1.1.0-SNAPSHOT are extremely misleading.
> >>>>>
> >>>>> I understand that is misleading, but at the same time it is convenient from a release pov, because we mass change the version only during release and it is set to the next "major" release that will happen from main branch... doing what you suggest would require to add some steps to the already long and tedious release process... I am not sure it is worth the effort but I admit I am biased being the one who does the releases 90% of the times :)
> >>>>
> >>>> It’s been years since I did a release, and I’m not sure the maven tools have gotten much better. However, I think the other camel subprojects have found a way to have the branch maven versions more correct. I think that “LTS” means to expect more releases on the branch, and changing the branch version from 0.12.0-SNAPSHOT to 0.11.1-SNAPSHOT before release seems extremely awkward to me.
> >>>
> >>> I will look into what other sub projects does thanks
> >>>> Thanks!
> >>>>
> >>>> David Jencks
> >>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> - Is 1.0.x LTS?
> >>>>>>> Yes it is, as it is 0.11.0
> >>>>>>
> >>>>>> I changed to this in my RI PR.
> >>>>>>
> >>>>>>>>
> >>>>>>>> - I guess it would make sense to change
> >>>>>>>>
> >>>>>>>> Camel Kafka Connector allows you to use all Camel components <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html>> as Kafka Connect <http://kafka.apache.org/documentation/#connect <http://kafka.apache.org/documentation/#connect>> connectors.
> >>>>>>>> to
> >>>>>>>> Camel Kafka Connector allows you to use all Kamelets as Kafka Connect <http://kafka.apache.org/documentation/#connect <http://kafka.apache.org/documentation/#connect>> connectors.*
> >>>>>>> +1 I agree
> >>>>>>
> >>>>>> Lets do that in another PR :-).
> >>>>>>>
> >>>>>>>>
> >>>>>>>> As part of the RI effort there’s a preview for c-k-c at https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>
> >>>>>>>>
> >>>>>>>> David Jencks
> >>>>>>
> >>>>>> The RI PRs are merged and the next and 0,11.x should be visible shortly.
> >>>>>>
> >>>>>> Thanks
> >>>>>> David Jencks
> >>
> >>
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: comments on c-k-c docs state && RI preview
Posted by David Jencks <da...@gmail.com>.
Putting the conclusion at the top….
https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>
I put the compatibility table at the bottom of the index page, added a kamelets column, and turned entries into links where plausible.
The table is also on the compatibility matrix page.
If the index page looks good, I’ll remove the compatibility page and squash everything.
No one has commented on whether such a table would be useful or desirable for other camel subprojects.
David Jencks
> On Jan 18, 2022, at 6:19 AM, Andrea <an...@tarocch.it> wrote:
>
>
>
> On Tue, Jan 18, 2022, at 05:55, David Jencks wrote:
>>
>>
>>> On Jan 17, 2022, at 1:50 PM, Andrea <an...@tarocch.it> wrote:
>>>
>>>
>>>
>>> On Mon, Jan 17, 2022, at 18:00, David Jencks wrote:
>>>>
>>>>
>>>>> On Jan 17, 2022, at 3:23 AM, Andrea <andrea@tarocch.it <ma...@tarocch.it>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 17, 2022, at 07:24, David Jencks wrote:
>>>>>> Thanks, inline...
>>>>>>
>>>>>>> On Jan 16, 2022, at 1:04 AM, Andrea <andrea@tarocch.it <ma...@tarocch.it>> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> comments inline:
>>>>>>>
>>>>>>> On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
>>>>>>>> I noticed a few things working on the RI info for camel-kafka-connector.
>>>>>>>>
>>>>>>>> - the compatibility matrices are thoroughly out of date, e.g. https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html> <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>>
>>>
>>> Awesome, basically a collection of the content of all these notes
>>> <image.png>
>>> could be the generated compatibility matrix page? Or is there already a way where that content is sown other that for the last release?
>>
>> Here’s a basic generated table for the compatibility matrix: https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/user-guide/camel-compatibility-matrix.html
>>
>> Note:
>> - it will only ever have one line per branch: there’s no way to have separate lines for e.g. 0.11.0, 0.11.1. 0.11.2, etc, since there is only one doc version that covers all of these.
>
> well in case it is needed we can always do a version from a tag
>> - It only has currently documented versions listed. This makes it self-maintaining: adding anything else will require periodic manual updates, which will gradually decay into wrong or outdated information.
>>
>> Are these acceptable limitations?
>
> fine for me
>>
>> - This version of the table isn’t quite finished: for instance the “branch” for next is wrong. If we like this generated table in principle, I can fix that and turn most entries into links.
>
> can you also add the version of the kamelet catalog?
>>
>> However, I’m not entirely sure that having this information duplicated/aggregated from the index pages is useful. I think we should just delete the compatibility matrix page. WDYT?
>
> as long as the table is somewhere I don't particularly care; it is fine to put it in the index page and remove the compatibility matrix page
>>
>> On the other hand, if this table is popular, maybe we should have one for each subproject.
>>
>> David Jencks
>>
>>>
>>>
>>>>>>> Yep the compatibility matrix page needs some love... a column mentioning kamelet catalog version needs to be added and probably we can remove some old rows?
>>>>>>> willing to help on this on too? :)
>>>>>>
>>>>>> I think the entire existing matrix is out of date and should be removed? Or are there usable versions of c-k-c that aren’t documented?
>>>>>>
>>>>>> I wonder if the RI information is sufficient, WDYT?
>>>>>
>>>>> Where can I see a preview of the site with the IR information?
>>>>
>>>> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html> <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html>> shows all three branches (including not-quite-released 1.0).
>>>>
>>>>>>
>>>>>> If you’re sure we need the matrix, let me know where it should start and I’ll make some PRs. I’d suggest having only one copy, perhaps in next, and referring to it from the other branches.
>>>>>>>
>>>>>>>>
>>>>>>>> - All other camel subprojects use e.g. 2.5.x as the Antora component version, but c-k-c is using 0.11.0. Especially since it’s LTS I think we should change it to 0.11.x so when 0.11.1 comes out the version still makes sense, as well as being consistent with the rest of the site. I’m setting the 1.0.x branch up to say 1.0.x as the Antora version.
>>>>>>> +1 I agree
>>>>>>>
>>>>>>
>>>>>> I’ve changed to 0.11.x in my RI PR.
>>>>>>
>>>>>>>>
>>>>>>>> - archetype-dataformat-connector has camel-version 3.6.0, rather out of date.
>>>>>>> What do you mean here?
>>>>>>
>>>>>> I should have looked harder and explained better. The example output shown in archetype-dataformat-connector.adoc shows using camel 3.6.0. This page should probably be updated, and I wonder if it is even relevant for the kamelet-based c-k-c.
>>>>>
>>>>> Yep for sure that part needs to be revisited and re-evaluated...
>>>>>>>
>>>>>>>>
>>>>>>>> - the maven versions in 1.0.x branch is 1.1.0-SNAPSHOT and for 0.11.x 0.12.0-SNAPSHOT. I think these should increment the micro version, not minor version?
>>>>>>> In theory you are right, in practice for convenience and based on how maven release plugin works and how we do releases, is more convenient to leave the version set as next release version even in the single releases branches... hoping to remember that once a new minor release of a release branch is needed.
>>>>>>>
>>>>>>> I admit that might be we are just being lazy and there is a reasonably hassle free way of handling this better?
>>>>>>
>>>>>> Perhaps I didn’t explain very well. Both 0.11.0 and 1.0.0 are LTS so we can expect releases on these branches. The next versions will be 0.11.1 and 1.0.1, so the current maven versions should be 0.11.1-SNAPSHOT and 1.0.1-SNAPSHOT, with the micro version incremented: the current 0.12.0-SNAPSHOT and 1.1.0-SNAPSHOT are extremely misleading.
>>>>>
>>>>> I understand that is misleading, but at the same time it is convenient from a release pov, because we mass change the version only during release and it is set to the next "major" release that will happen from main branch... doing what you suggest would require to add some steps to the already long and tedious release process... I am not sure it is worth the effort but I admit I am biased being the one who does the releases 90% of the times :)
>>>>
>>>> It’s been years since I did a release, and I’m not sure the maven tools have gotten much better. However, I think the other camel subprojects have found a way to have the branch maven versions more correct. I think that “LTS” means to expect more releases on the branch, and changing the branch version from 0.12.0-SNAPSHOT to 0.11.1-SNAPSHOT before release seems extremely awkward to me.
>>>
>>> I will look into what other sub projects does thanks
>>>> Thanks!
>>>>
>>>> David Jencks
>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> - Is 1.0.x LTS?
>>>>>>> Yes it is, as it is 0.11.0
>>>>>>
>>>>>> I changed to this in my RI PR.
>>>>>>
>>>>>>>>
>>>>>>>> - I guess it would make sense to change
>>>>>>>>
>>>>>>>> Camel Kafka Connector allows you to use all Camel components <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html>> as Kafka Connect <http://kafka.apache.org/documentation/#connect <http://kafka.apache.org/documentation/#connect>> connectors.
>>>>>>>> to
>>>>>>>> Camel Kafka Connector allows you to use all Kamelets as Kafka Connect <http://kafka.apache.org/documentation/#connect <http://kafka.apache.org/documentation/#connect>> connectors.*
>>>>>>> +1 I agree
>>>>>>
>>>>>> Lets do that in another PR :-).
>>>>>>>
>>>>>>>>
>>>>>>>> As part of the RI effort there’s a preview for c-k-c at https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>
>>>>>>>>
>>>>>>>> David Jencks
>>>>>>
>>>>>> The RI PRs are merged and the next and 0,11.x should be visible shortly.
>>>>>>
>>>>>> Thanks
>>>>>> David Jencks
>>
>>
Re: comments on c-k-c docs state && RI preview
Posted by Andrea <an...@tarocch.it>.
On Tue, Jan 18, 2022, at 05:55, David Jencks wrote:
>
>
> > On Jan 17, 2022, at 1:50 PM, Andrea <an...@tarocch.it> wrote:
> >
> >
> >
> > On Mon, Jan 17, 2022, at 18:00, David Jencks wrote:
> >>
> >>
> >> > On Jan 17, 2022, at 3:23 AM, Andrea <andrea@tarocch.it <ma...@tarocch.it>> wrote:
> >> >
> >> >
> >> >
> >> > On Mon, Jan 17, 2022, at 07:24, David Jencks wrote:
> >> >> Thanks, inline...
> >> >>
> >> >>> On Jan 16, 2022, at 1:04 AM, Andrea <andrea@tarocch.it <ma...@tarocch.it>> wrote:
> >> >>>
> >> >>> Hello,
> >> >>>
> >> >>> comments inline:
> >> >>>
> >> >>> On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
> >> >>>> I noticed a few things working on the RI info for camel-kafka-connector.
> >> >>>>
> >> >>>> - the compatibility matrices are thoroughly out of date, e.g. https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html> <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>>
> >
> > Awesome, basically a collection of the content of all these notes
> > <image.png>
> > could be the generated compatibility matrix page? Or is there already a way where that content is sown other that for the last release?
>
> Here’s a basic generated table for the compatibility matrix: https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/user-guide/camel-compatibility-matrix.html
>
> Note:
> - it will only ever have one line per branch: there’s no way to have separate lines for e.g. 0.11.0, 0.11.1. 0.11.2, etc, since there is only one doc version that covers all of these.
well in case it is needed we can always do a version from a tag
> - It only has currently documented versions listed. This makes it self-maintaining: adding anything else will require periodic manual updates, which will gradually decay into wrong or outdated information.
>
> Are these acceptable limitations?
fine for me
>
> - This version of the table isn’t quite finished: for instance the “branch” for next is wrong. If we like this generated table in principle, I can fix that and turn most entries into links.
can you also add the version of the kamelet catalog?
>
> However, I’m not entirely sure that having this information duplicated/aggregated from the index pages is useful. I think we should just delete the compatibility matrix page. WDYT?
as long as the table is somewhere I don't particularly care; it is fine to put it in the index page and remove the compatibility matrix page
>
> On the other hand, if this table is popular, maybe we should have one for each subproject.
>
> David Jencks
>
> >
> >
> >> >>> Yep the compatibility matrix page needs some love... a column mentioning kamelet catalog version needs to be added and probably we can remove some old rows?
> >> >>> willing to help on this on too? :)
> >> >>
> >> >> I think the entire existing matrix is out of date and should be removed? Or are there usable versions of c-k-c that aren’t documented?
> >> >>
> >> >> I wonder if the RI information is sufficient, WDYT?
> >> >
> >> > Where can I see a preview of the site with the IR information?
> >>
> >> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html> <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html>> shows all three branches (including not-quite-released 1.0).
> >>
> >> >>
> >> >> If you’re sure we need the matrix, let me know where it should start and I’ll make some PRs. I’d suggest having only one copy, perhaps in next, and referring to it from the other branches.
> >> >>>
> >> >>>>
> >> >>>> - All other camel subprojects use e.g. 2.5.x as the Antora component version, but c-k-c is using 0.11.0. Especially since it’s LTS I think we should change it to 0.11.x so when 0.11.1 comes out the version still makes sense, as well as being consistent with the rest of the site. I’m setting the 1.0.x branch up to say 1.0.x as the Antora version.
> >> >>> +1 I agree
> >> >>>
> >> >>
> >> >> I’ve changed to 0.11.x in my RI PR.
> >> >>
> >> >>>>
> >> >>>> - archetype-dataformat-connector has camel-version 3.6.0, rather out of date.
> >> >>> What do you mean here?
> >> >>
> >> >> I should have looked harder and explained better. The example output shown in archetype-dataformat-connector.adoc shows using camel 3.6.0. This page should probably be updated, and I wonder if it is even relevant for the kamelet-based c-k-c.
> >> >
> >> > Yep for sure that part needs to be revisited and re-evaluated...
> >> >>>
> >> >>>>
> >> >>>> - the maven versions in 1.0.x branch is 1.1.0-SNAPSHOT and for 0.11.x 0.12.0-SNAPSHOT. I think these should increment the micro version, not minor version?
> >> >>> In theory you are right, in practice for convenience and based on how maven release plugin works and how we do releases, is more convenient to leave the version set as next release version even in the single releases branches... hoping to remember that once a new minor release of a release branch is needed.
> >> >>>
> >> >>> I admit that might be we are just being lazy and there is a reasonably hassle free way of handling this better?
> >> >>
> >> >> Perhaps I didn’t explain very well. Both 0.11.0 and 1.0.0 are LTS so we can expect releases on these branches. The next versions will be 0.11.1 and 1.0.1, so the current maven versions should be 0.11.1-SNAPSHOT and 1.0.1-SNAPSHOT, with the micro version incremented: the current 0.12.0-SNAPSHOT and 1.1.0-SNAPSHOT are extremely misleading.
> >> >
> >> > I understand that is misleading, but at the same time it is convenient from a release pov, because we mass change the version only during release and it is set to the next "major" release that will happen from main branch... doing what you suggest would require to add some steps to the already long and tedious release process... I am not sure it is worth the effort but I admit I am biased being the one who does the releases 90% of the times :)
> >>
> >> It’s been years since I did a release, and I’m not sure the maven tools have gotten much better. However, I think the other camel subprojects have found a way to have the branch maven versions more correct. I think that “LTS” means to expect more releases on the branch, and changing the branch version from 0.12.0-SNAPSHOT to 0.11.1-SNAPSHOT before release seems extremely awkward to me.
> >
> > I will look into what other sub projects does thanks
> >> Thanks!
> >>
> >> David Jencks
> >>
> >> >>>
> >> >>>>
> >> >>>> - Is 1.0.x LTS?
> >> >>> Yes it is, as it is 0.11.0
> >> >>
> >> >> I changed to this in my RI PR.
> >> >>
> >> >>>>
> >> >>>> - I guess it would make sense to change
> >> >>>>
> >> >>>> Camel Kafka Connector allows you to use all Camel components <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html>> as Kafka Connect <http://kafka.apache.org/documentation/#connect <http://kafka.apache.org/documentation/#connect>> connectors.
> >> >>>> to
> >> >>>> Camel Kafka Connector allows you to use all Kamelets as Kafka Connect <http://kafka.apache.org/documentation/#connect <http://kafka.apache.org/documentation/#connect>> connectors.*
> >> >>> +1 I agree
> >> >>
> >> >> Lets do that in another PR :-).
> >> >>>
> >> >>>>
> >> >>>> As part of the RI effort there’s a preview for c-k-c at https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>
> >> >>>>
> >> >>>> David Jencks
> >> >>
> >> >> The RI PRs are merged and the next and 0,11.x should be visible shortly.
> >> >>
> >> >> Thanks
> >> >> David Jencks
>
>
Re: comments on c-k-c docs state && RI preview
Posted by David Jencks <da...@gmail.com>.
> On Jan 17, 2022, at 1:50 PM, Andrea <an...@tarocch.it> wrote:
>
>
>
> On Mon, Jan 17, 2022, at 18:00, David Jencks wrote:
>>
>>
>> > On Jan 17, 2022, at 3:23 AM, Andrea <andrea@tarocch.it <ma...@tarocch.it>> wrote:
>> >
>> >
>> >
>> > On Mon, Jan 17, 2022, at 07:24, David Jencks wrote:
>> >> Thanks, inline...
>> >>
>> >>> On Jan 16, 2022, at 1:04 AM, Andrea <andrea@tarocch.it <ma...@tarocch.it>> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> comments inline:
>> >>>
>> >>> On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
>> >>>> I noticed a few things working on the RI info for camel-kafka-connector.
>> >>>>
>> >>>> - the compatibility matrices are thoroughly out of date, e.g. https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html> <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>>
>
> Awesome, basically a collection of the content of all these notes
> <image.png>
> could be the generated compatibility matrix page? Or is there already a way where that content is sown other that for the last release?
Here’s a basic generated table for the compatibility matrix: https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/user-guide/camel-compatibility-matrix.html
Note:
- it will only ever have one line per branch: there’s no way to have separate lines for e.g. 0.11.0, 0.11.1. 0.11.2, etc, since there is only one doc version that covers all of these.
- It only has currently documented versions listed. This makes it self-maintaining: adding anything else will require periodic manual updates, which will gradually decay into wrong or outdated information.
Are these acceptable limitations?
- This version of the table isn’t quite finished: for instance the “branch” for next is wrong. If we like this generated table in principle, I can fix that and turn most entries into links.
However, I’m not entirely sure that having this information duplicated/aggregated from the index pages is useful. I think we should just delete the compatibility matrix page. WDYT?
On the other hand, if this table is popular, maybe we should have one for each subproject.
David Jencks
>
>
>> >>> Yep the compatibility matrix page needs some love... a column mentioning kamelet catalog version needs to be added and probably we can remove some old rows?
>> >>> willing to help on this on too? :)
>> >>
>> >> I think the entire existing matrix is out of date and should be removed? Or are there usable versions of c-k-c that aren’t documented?
>> >>
>> >> I wonder if the RI information is sufficient, WDYT?
>> >
>> > Where can I see a preview of the site with the IR information?
>>
>> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html> <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html>> shows all three branches (including not-quite-released 1.0).
>>
>> >>
>> >> If you’re sure we need the matrix, let me know where it should start and I’ll make some PRs. I’d suggest having only one copy, perhaps in next, and referring to it from the other branches.
>> >>>
>> >>>>
>> >>>> - All other camel subprojects use e.g. 2.5.x as the Antora component version, but c-k-c is using 0.11.0. Especially since it’s LTS I think we should change it to 0.11.x so when 0.11.1 comes out the version still makes sense, as well as being consistent with the rest of the site. I’m setting the 1.0.x branch up to say 1.0.x as the Antora version.
>> >>> +1 I agree
>> >>>
>> >>
>> >> I’ve changed to 0.11.x in my RI PR.
>> >>
>> >>>>
>> >>>> - archetype-dataformat-connector has camel-version 3.6.0, rather out of date.
>> >>> What do you mean here?
>> >>
>> >> I should have looked harder and explained better. The example output shown in archetype-dataformat-connector.adoc shows using camel 3.6.0. This page should probably be updated, and I wonder if it is even relevant for the kamelet-based c-k-c.
>> >
>> > Yep for sure that part needs to be revisited and re-evaluated...
>> >>>
>> >>>>
>> >>>> - the maven versions in 1.0.x branch is 1.1.0-SNAPSHOT and for 0.11.x 0.12.0-SNAPSHOT. I think these should increment the micro version, not minor version?
>> >>> In theory you are right, in practice for convenience and based on how maven release plugin works and how we do releases, is more convenient to leave the version set as next release version even in the single releases branches... hoping to remember that once a new minor release of a release branch is needed.
>> >>>
>> >>> I admit that might be we are just being lazy and there is a reasonably hassle free way of handling this better?
>> >>
>> >> Perhaps I didn’t explain very well. Both 0.11.0 and 1.0.0 are LTS so we can expect releases on these branches. The next versions will be 0.11.1 and 1.0.1, so the current maven versions should be 0.11.1-SNAPSHOT and 1.0.1-SNAPSHOT, with the micro version incremented: the current 0.12.0-SNAPSHOT and 1.1.0-SNAPSHOT are extremely misleading.
>> >
>> > I understand that is misleading, but at the same time it is convenient from a release pov, because we mass change the version only during release and it is set to the next "major" release that will happen from main branch... doing what you suggest would require to add some steps to the already long and tedious release process... I am not sure it is worth the effort but I admit I am biased being the one who does the releases 90% of the times :)
>>
>> It’s been years since I did a release, and I’m not sure the maven tools have gotten much better. However, I think the other camel subprojects have found a way to have the branch maven versions more correct. I think that “LTS” means to expect more releases on the branch, and changing the branch version from 0.12.0-SNAPSHOT to 0.11.1-SNAPSHOT before release seems extremely awkward to me.
>
> I will look into what other sub projects does thanks
>> Thanks!
>>
>> David Jencks
>>
>> >>>
>> >>>>
>> >>>> - Is 1.0.x LTS?
>> >>> Yes it is, as it is 0.11.0
>> >>
>> >> I changed to this in my RI PR.
>> >>
>> >>>>
>> >>>> - I guess it would make sense to change
>> >>>>
>> >>>> Camel Kafka Connector allows you to use all Camel components <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html>> as Kafka Connect <http://kafka.apache.org/documentation/#connect <http://kafka.apache.org/documentation/#connect>> connectors.
>> >>>> to
>> >>>> Camel Kafka Connector allows you to use all Kamelets as Kafka Connect <http://kafka.apache.org/documentation/#connect <http://kafka.apache.org/documentation/#connect>> connectors.*
>> >>> +1 I agree
>> >>
>> >> Lets do that in another PR :-).
>> >>>
>> >>>>
>> >>>> As part of the RI effort there’s a preview for c-k-c at https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html>
>> >>>>
>> >>>> David Jencks
>> >>
>> >> The RI PRs are merged and the next and 0,11.x should be visible shortly.
>> >>
>> >> Thanks
>> >> David Jencks
Re: comments on c-k-c docs state && RI preview
Posted by Andrea <an...@tarocch.it>.
On Mon, Jan 17, 2022, at 18:00, David Jencks wrote:
>
>
> > On Jan 17, 2022, at 3:23 AM, Andrea <an...@tarocch.it> wrote:
> >
> >
> >
> > On Mon, Jan 17, 2022, at 07:24, David Jencks wrote:
> >> Thanks, inline...
> >>
> >>> On Jan 16, 2022, at 1:04 AM, Andrea <an...@tarocch.it> wrote:
> >>>
> >>> Hello,
> >>>
> >>> comments inline:
> >>>
> >>> On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
> >>>> I noticed a few things working on the RI info for camel-kafka-connector.
> >>>>
> >>>> - the compatibility matrices are thoroughly out of date, e.g. https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>
Awesome, basically a collection of the content of all these notes
could be the generated compatibility matrix page? Or is there already a way where that content is sown other that for the last release?
> >>> Yep the compatibility matrix page needs some love... a column mentioning kamelet catalog version needs to be added and probably we can remove some old rows?
> >>> willing to help on this on too? :)
> >>
> >> I think the entire existing matrix is out of date and should be removed? Or are there usable versions of c-k-c that aren’t documented?
> >>
> >> I wonder if the RI information is sufficient, WDYT?
> >
> > Where can I see a preview of the site with the IR information?
>
> https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html> shows all three branches (including not-quite-released 1.0).
>
> >>
> >> If you’re sure we need the matrix, let me know where it should start and I’ll make some PRs. I’d suggest having only one copy, perhaps in next, and referring to it from the other branches.
> >>>
> >>>>
> >>>> - All other camel subprojects use e.g. 2.5.x as the Antora component version, but c-k-c is using 0.11.0. Especially since it’s LTS I think we should change it to 0.11.x so when 0.11.1 comes out the version still makes sense, as well as being consistent with the rest of the site. I’m setting the 1.0.x branch up to say 1.0.x as the Antora version.
> >>> +1 I agree
> >>>
> >>
> >> I’ve changed to 0.11.x in my RI PR.
> >>
> >>>>
> >>>> - archetype-dataformat-connector has camel-version 3.6.0, rather out of date.
> >>> What do you mean here?
> >>
> >> I should have looked harder and explained better. The example output shown in archetype-dataformat-connector.adoc shows using camel 3.6.0. This page should probably be updated, and I wonder if it is even relevant for the kamelet-based c-k-c.
> >
> > Yep for sure that part needs to be revisited and re-evaluated...
> >>>
> >>>>
> >>>> - the maven versions in 1.0.x branch is 1.1.0-SNAPSHOT and for 0.11.x 0.12.0-SNAPSHOT. I think these should increment the micro version, not minor version?
> >>> In theory you are right, in practice for convenience and based on how maven release plugin works and how we do releases, is more convenient to leave the version set as next release version even in the single releases branches... hoping to remember that once a new minor release of a release branch is needed.
> >>>
> >>> I admit that might be we are just being lazy and there is a reasonably hassle free way of handling this better?
> >>
> >> Perhaps I didn’t explain very well. Both 0.11.0 and 1.0.0 are LTS so we can expect releases on these branches. The next versions will be 0.11.1 and 1.0.1, so the current maven versions should be 0.11.1-SNAPSHOT and 1.0.1-SNAPSHOT, with the micro version incremented: the current 0.12.0-SNAPSHOT and 1.1.0-SNAPSHOT are extremely misleading.
> >
> > I understand that is misleading, but at the same time it is convenient from a release pov, because we mass change the version only during release and it is set to the next "major" release that will happen from main branch... doing what you suggest would require to add some steps to the already long and tedious release process... I am not sure it is worth the effort but I admit I am biased being the one who does the releases 90% of the times :)
>
> It’s been years since I did a release, and I’m not sure the maven tools have gotten much better. However, I think the other camel subprojects have found a way to have the branch maven versions more correct. I think that “LTS” means to expect more releases on the branch, and changing the branch version from 0.12.0-SNAPSHOT to 0.11.1-SNAPSHOT before release seems extremely awkward to me.
I will look into what other sub projects does thanks
> Thanks!
>
> David Jencks
>
> >>>
> >>>>
> >>>> - Is 1.0.x LTS?
> >>> Yes it is, as it is 0.11.0
> >>
> >> I changed to this in my RI PR.
> >>
> >>>>
> >>>> - I guess it would make sense to change
> >>>>
> >>>> Camel Kafka Connector allows you to use all Camel components <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html> as Kafka Connect <http://kafka.apache.org/documentation/#connect> connectors.
> >>>> to
> >>>> Camel Kafka Connector allows you to use all Kamelets as Kafka Connect <http://kafka.apache.org/documentation/#connect> connectors.*
> >>> +1 I agree
> >>
> >> Lets do that in another PR :-).
> >>>
> >>>>
> >>>> As part of the RI effort there’s a preview for c-k-c at https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html
> >>>>
> >>>> David Jencks
> >>
> >> The RI PRs are merged and the next and 0,11.x should be visible shortly.
> >>
> >> Thanks
> >> David Jencks
>
>
Re: comments on c-k-c docs state && RI preview
Posted by David Jencks <da...@gmail.com>.
> On Jan 17, 2022, at 3:23 AM, Andrea <an...@tarocch.it> wrote:
>
>
>
> On Mon, Jan 17, 2022, at 07:24, David Jencks wrote:
>> Thanks, inline...
>>
>>> On Jan 16, 2022, at 1:04 AM, Andrea <an...@tarocch.it> wrote:
>>>
>>> Hello,
>>>
>>> comments inline:
>>>
>>> On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
>>>> I noticed a few things working on the RI info for camel-kafka-connector.
>>>>
>>>> - the compatibility matrices are thoroughly out of date, e.g. https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>
>>> Yep the compatibility matrix page needs some love... a column mentioning kamelet catalog version needs to be added and probably we can remove some old rows?
>>> willing to help on this on too? :)
>>
>> I think the entire existing matrix is out of date and should be removed? Or are there usable versions of c-k-c that aren’t documented?
>>
>> I wonder if the RI information is sufficient, WDYT?
>
> Where can I see a preview of the site with the IR information?
https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html <https://pr-747--camel.netlify.app/camel-kafka-connector/1.0.x/index.html> shows all three branches (including not-quite-released 1.0).
>>
>> If you’re sure we need the matrix, let me know where it should start and I’ll make some PRs. I’d suggest having only one copy, perhaps in next, and referring to it from the other branches.
>>>
>>>>
>>>> - All other camel subprojects use e.g. 2.5.x as the Antora component version, but c-k-c is using 0.11.0. Especially since it’s LTS I think we should change it to 0.11.x so when 0.11.1 comes out the version still makes sense, as well as being consistent with the rest of the site. I’m setting the 1.0.x branch up to say 1.0.x as the Antora version.
>>> +1 I agree
>>>
>>
>> I’ve changed to 0.11.x in my RI PR.
>>
>>>>
>>>> - archetype-dataformat-connector has camel-version 3.6.0, rather out of date.
>>> What do you mean here?
>>
>> I should have looked harder and explained better. The example output shown in archetype-dataformat-connector.adoc shows using camel 3.6.0. This page should probably be updated, and I wonder if it is even relevant for the kamelet-based c-k-c.
>
> Yep for sure that part needs to be revisited and re-evaluated...
>>>
>>>>
>>>> - the maven versions in 1.0.x branch is 1.1.0-SNAPSHOT and for 0.11.x 0.12.0-SNAPSHOT. I think these should increment the micro version, not minor version?
>>> In theory you are right, in practice for convenience and based on how maven release plugin works and how we do releases, is more convenient to leave the version set as next release version even in the single releases branches... hoping to remember that once a new minor release of a release branch is needed.
>>>
>>> I admit that might be we are just being lazy and there is a reasonably hassle free way of handling this better?
>>
>> Perhaps I didn’t explain very well. Both 0.11.0 and 1.0.0 are LTS so we can expect releases on these branches. The next versions will be 0.11.1 and 1.0.1, so the current maven versions should be 0.11.1-SNAPSHOT and 1.0.1-SNAPSHOT, with the micro version incremented: the current 0.12.0-SNAPSHOT and 1.1.0-SNAPSHOT are extremely misleading.
>
> I understand that is misleading, but at the same time it is convenient from a release pov, because we mass change the version only during release and it is set to the next "major" release that will happen from main branch... doing what you suggest would require to add some steps to the already long and tedious release process... I am not sure it is worth the effort but I admit I am biased being the one who does the releases 90% of the times :)
It’s been years since I did a release, and I’m not sure the maven tools have gotten much better. However, I think the other camel subprojects have found a way to have the branch maven versions more correct. I think that “LTS” means to expect more releases on the branch, and changing the branch version from 0.12.0-SNAPSHOT to 0.11.1-SNAPSHOT before release seems extremely awkward to me.
Thanks!
David Jencks
>>>
>>>>
>>>> - Is 1.0.x LTS?
>>> Yes it is, as it is 0.11.0
>>
>> I changed to this in my RI PR.
>>
>>>>
>>>> - I guess it would make sense to change
>>>>
>>>> Camel Kafka Connector allows you to use all Camel components <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html> as Kafka Connect <http://kafka.apache.org/documentation/#connect> connectors.
>>>> to
>>>> Camel Kafka Connector allows you to use all Kamelets as Kafka Connect <http://kafka.apache.org/documentation/#connect> connectors.*
>>> +1 I agree
>>
>> Lets do that in another PR :-).
>>>
>>>>
>>>> As part of the RI effort there’s a preview for c-k-c at https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html
>>>>
>>>> David Jencks
>>
>> The RI PRs are merged and the next and 0,11.x should be visible shortly.
>>
>> Thanks
>> David Jencks
Re: comments on c-k-c docs state && RI preview
Posted by Andrea <an...@tarocch.it>.
On Mon, Jan 17, 2022, at 07:24, David Jencks wrote:
> Thanks, inline...
>
> > On Jan 16, 2022, at 1:04 AM, Andrea <an...@tarocch.it> wrote:
> >
> > Hello,
> >
> > comments inline:
> >
> > On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
> >> I noticed a few things working on the RI info for camel-kafka-connector.
> >>
> >> - the compatibility matrices are thoroughly out of date, e.g. https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>
> > Yep the compatibility matrix page needs some love... a column mentioning kamelet catalog version needs to be added and probably we can remove some old rows?
> > willing to help on this on too? :)
>
> I think the entire existing matrix is out of date and should be removed? Or are there usable versions of c-k-c that aren’t documented?
>
> I wonder if the RI information is sufficient, WDYT?
Where can I see a preview of the site with the IR information?
>
> If you’re sure we need the matrix, let me know where it should start and I’ll make some PRs. I’d suggest having only one copy, perhaps in next, and referring to it from the other branches.
> >
> >>
> >> - All other camel subprojects use e.g. 2.5.x as the Antora component version, but c-k-c is using 0.11.0. Especially since it’s LTS I think we should change it to 0.11.x so when 0.11.1 comes out the version still makes sense, as well as being consistent with the rest of the site. I’m setting the 1.0.x branch up to say 1.0.x as the Antora version.
> > +1 I agree
> >
>
> I’ve changed to 0.11.x in my RI PR.
>
> >>
> >> - archetype-dataformat-connector has camel-version 3.6.0, rather out of date.
> > What do you mean here?
>
> I should have looked harder and explained better. The example output shown in archetype-dataformat-connector.adoc shows using camel 3.6.0. This page should probably be updated, and I wonder if it is even relevant for the kamelet-based c-k-c.
Yep for sure that part needs to be revisited and re-evaluated...
> >
> >>
> >> - the maven versions in 1.0.x branch is 1.1.0-SNAPSHOT and for 0.11.x 0.12.0-SNAPSHOT. I think these should increment the micro version, not minor version?
> > In theory you are right, in practice for convenience and based on how maven release plugin works and how we do releases, is more convenient to leave the version set as next release version even in the single releases branches... hoping to remember that once a new minor release of a release branch is needed.
> >
> > I admit that might be we are just being lazy and there is a reasonably hassle free way of handling this better?
>
> Perhaps I didn’t explain very well. Both 0.11.0 and 1.0.0 are LTS so we can expect releases on these branches. The next versions will be 0.11.1 and 1.0.1, so the current maven versions should be 0.11.1-SNAPSHOT and 1.0.1-SNAPSHOT, with the micro version incremented: the current 0.12.0-SNAPSHOT and 1.1.0-SNAPSHOT are extremely misleading.
I understand that is misleading, but at the same time it is convenient from a release pov, because we mass change the version only during release and it is set to the next "major" release that will happen from main branch... doing what you suggest would require to add some steps to the already long and tedious release process... I am not sure it is worth the effort but I admit I am biased being the one who does the releases 90% of the times :)
> >
> >>
> >> - Is 1.0.x LTS?
> > Yes it is, as it is 0.11.0
>
> I changed to this in my RI PR.
>
> >>
> >> - I guess it would make sense to change
> >>
> >> Camel Kafka Connector allows you to use all Camel components <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html> as Kafka Connect <http://kafka.apache.org/documentation/#connect> connectors.
> >> to
> >> Camel Kafka Connector allows you to use all Kamelets as Kafka Connect <http://kafka.apache.org/documentation/#connect> connectors.*
> > +1 I agree
>
> Lets do that in another PR :-).
> >
> >>
> >> As part of the RI effort there’s a preview for c-k-c at https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html
> >>
> >> David Jencks
>
> The RI PRs are merged and the next and 0,11.x should be visible shortly.
>
> Thanks
> David Jencks
>
>
Re: comments on c-k-c docs state && RI preview
Posted by David Jencks <da...@gmail.com>.
Thanks, inline...
> On Jan 16, 2022, at 1:04 AM, Andrea <an...@tarocch.it> wrote:
>
> Hello,
>
> comments inline:
>
> On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
>> I noticed a few things working on the RI info for camel-kafka-connector.
>>
>> - the compatibility matrices are thoroughly out of date, e.g. https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>
> Yep the compatibility matrix page needs some love... a column mentioning kamelet catalog version needs to be added and probably we can remove some old rows?
> willing to help on this on too? :)
I think the entire existing matrix is out of date and should be removed? Or are there usable versions of c-k-c that aren’t documented?
I wonder if the RI information is sufficient, WDYT?
If you’re sure we need the matrix, let me know where it should start and I’ll make some PRs. I’d suggest having only one copy, perhaps in next, and referring to it from the other branches.
>
>>
>> - All other camel subprojects use e.g. 2.5.x as the Antora component version, but c-k-c is using 0.11.0. Especially since it’s LTS I think we should change it to 0.11.x so when 0.11.1 comes out the version still makes sense, as well as being consistent with the rest of the site. I’m setting the 1.0.x branch up to say 1.0.x as the Antora version.
> +1 I agree
>
I’ve changed to 0.11.x in my RI PR.
>>
>> - archetype-dataformat-connector has camel-version 3.6.0, rather out of date.
> What do you mean here?
I should have looked harder and explained better. The example output shown in archetype-dataformat-connector.adoc shows using camel 3.6.0. This page should probably be updated, and I wonder if it is even relevant for the kamelet-based c-k-c.
>
>>
>> - the maven versions in 1.0.x branch is 1.1.0-SNAPSHOT and for 0.11.x 0.12.0-SNAPSHOT. I think these should increment the micro version, not minor version?
> In theory you are right, in practice for convenience and based on how maven release plugin works and how we do releases, is more convenient to leave the version set as next release version even in the single releases branches... hoping to remember that once a new minor release of a release branch is needed.
>
> I admit that might be we are just being lazy and there is a reasonably hassle free way of handling this better?
Perhaps I didn’t explain very well. Both 0.11.0 and 1.0.0 are LTS so we can expect releases on these branches. The next versions will be 0.11.1 and 1.0.1, so the current maven versions should be 0.11.1-SNAPSHOT and 1.0.1-SNAPSHOT, with the micro version incremented: the current 0.12.0-SNAPSHOT and 1.1.0-SNAPSHOT are extremely misleading.
>
>>
>> - Is 1.0.x LTS?
> Yes it is, as it is 0.11.0
I changed to this in my RI PR.
>>
>> - I guess it would make sense to change
>>
>> Camel Kafka Connector allows you to use all Camel components <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html> as Kafka Connect <http://kafka.apache.org/documentation/#connect> connectors.
>> to
>> Camel Kafka Connector allows you to use all Kamelets as Kafka Connect <http://kafka.apache.org/documentation/#connect> connectors.*
> +1 I agree
Lets do that in another PR :-).
>
>>
>> As part of the RI effort there’s a preview for c-k-c at https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html
>>
>> David Jencks
The RI PRs are merged and the next and 0,11.x should be visible shortly.
Thanks
David Jencks
Re: comments on c-k-c docs state && RI preview
Posted by Andrea <an...@tarocch.it>.
Hello,
comments inline:
On Sat, Jan 15, 2022, at 06:37, David Jencks wrote:
> I noticed a few things working on the RI info for camel-kafka-connector.
>
> - the compatibility matrices are thoroughly out of date, e.g. https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html <https://camel.apache.org/camel-kafka-connector/0.11.0/user-guide/camel-compatibility-matrix.html>
Yep the compatibility matrix page needs some love... a column mentioning kamelet catalog version needs to be added and probably we can remove some old rows?
willing to help on this on too? :)
>
> - All other camel subprojects use e.g. 2.5.x as the Antora component version, but c-k-c is using 0.11.0. Especially since it’s LTS I think we should change it to 0.11.x so when 0.11.1 comes out the version still makes sense, as well as being consistent with the rest of the site. I’m setting the 1.0.x branch up to say 1.0.x as the Antora version.
+1 I agree
>
> - archetype-dataformat-connector has camel-version 3.6.0, rather out of date.
What do you mean here?
>
> - the maven versions in 1.0.x branch is 1.1.0-SNAPSHOT and for 0.11.x 0.12.0-SNAPSHOT. I think these should increment the micro version, not minor version?
In theory you are right, in practice for convenience and based on how maven release plugin works and how we do releases, is more convenient to leave the version set as next release version even in the single releases branches... hoping to remember that once a new minor release of a release branch is needed.
I admit that might be we are just being lazy and there is a reasonably hassle free way of handling this better?
>
> - Is 1.0.x LTS?
Yes it is, as it is 0.11.0
>
> - I guess it would make sense to change
>
> Camel Kafka Connector allows you to use all Camel components <applewebdata://26B8BDA8-8AF9-4D43-86E9-44E7AD9124B6/components/3.14.x/index.html> as Kafka Connect <http://kafka.apache.org/documentation/#connect> connectors.
> to
> Camel Kafka Connector allows you to use all Kamelets as Kafka Connect <http://kafka.apache.org/documentation/#connect> connectors.*
+1 I agree
>
> As part of the RI effort there’s a preview for c-k-c at https://pr-747--camel.netlify.app/camel-kafka-connector/next/index.html
>
> David Jencks