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