On Mon, Jan 17, 2022, at 18:00, David Jencks wrote: > > > > On Jan 17, 2022, at 3:23 AM, Andrea <and...@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 <and...@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 > >
