> On Sep 19, 2021, at 10:20 PM, Claus Ibsen <[email protected]> wrote: > > On Sun, Sep 19, 2021 at 1:46 AM David Jencks <[email protected] > <mailto:[email protected]>> wrote: >> >> Now I have more questions :-\ >> >> IIUC the latest (code) release is 3.11.2. Is this what is documented in the >> 3.11.x doc version? >> Does the doc ‘latest’ version document unreleased code, i.e. the current >> state of the ‘main’ branch? If so, would it be appropriate to make it a >> pre-release version? >> > > Yeah latest is the current main code, but a good idea to rename it to > pre-release or something like that.
Antora has the concept of marking a version ‘pre-release’. The main effect is that it’s no longer the (Antora) “latest” version: right now, if we marked “latest” pre-release, then the Antora “latest” version in components would be 3.11.x. In particular, xrefs to “components” pages from other Antora components, where the xref doesn’t specify the version, will go to 3.11.x rather than “latest”. Since according to apache policy we shouldn’t be encouraging users to use unreleased code, making the docs for the unreleased code harder to get to and marked is probably a good idea:-). We always know what version “latest” is going to be related as, so how about labeling is with that version? That would give us, for camel itself, `3.12 (prerelease)` rather than `latest` or ‘latest (prerelease)`. > >> Is 3.12 (non-LTS, IIUC) going to get a doc version other than ‘latest’? >> > > Yeah the last release is there, eg 3.12.0, 3.13.0 and so on. But a non > LTS is removed asap a new release is out, so 3.12.0 is removed when > 3.13.0 is released. > Makes sense! >> Apparently 3.4.x (LTS) went out of support sometime around last July. Would >> it be appropriate to remove the doc version or label it out of support, >> perhaps (LTS expired)? >> > > Yeah lets remove it I’ll make a PR. > >> In general, it might be nice to include the expiration date of LTS versions >> somewhere prominent in the docs, perhaps the components index page. >> > > The EOL date is listed on downloads, which IMHO is a natural place for > such information > https://camel.apache.org/download/ <https://camel.apache.org/download/> if the downloads page was an Antora page we could both generate it from a json or yaml file and also include the EOL date elsewhere using asciidoctor-jsonpath. It looks like the current downloads page is generated somehow but I don’t see how or where the data comes from. David Jencks > > > >> too many questions…. >> >> Thanks >> David Jencks >> >> >> >>> On Sep 18, 2021, at 12:31 AM, Zoran Regvart <[email protected]> wrote: >>> >>> Hi David & Cameleers, >>> as far as I’m aware, all sub-projects lag behind the latest Camel version. >>> I don’t know if that’s a problem, they usually are not very far behind. >>> For the documentation and Camel Quarkus in particular, the past experience >>> was that pointing to the latest Camel version often led to broken links so >>> not changing the version led to greater stability of the website. >>> I do think that documentation should be cross linked against the correct >>> versions, i.e. the ones they depend on in the code and that version should >>> be prominently displayed in the documentation. >>> >>> zoran >>> -- >>> Sent from mobile >>> >>>> On 16. Sep 2021, at 22:10, David Jencks <[email protected]> wrote: >>>> >>>> While fixing the broken camel-quarkus partial website build I noticed a >>>> couple of things I don’t understand. >>>> >>>> 1. camel-quarkus latest seems to use camel 3.11.x, at least the docs do. >>>> I think that, if this is really correct, the camel-quarkus index page >>>> should prominently say that you aren’t getting the cutting-edge latest >>>> camel in camel-quarkus, but something slightly older. Naively, I expected >>>> camel-quarkus versions to track camel versions. Indicating the >>>> relationship between versions would certainly help me. >>>> >>>> 2. eips are now versioned with components, but at least some links from >>>> components to eips use {eip-vc} in >>>> xref:{eip-vc}:eips:polling-consumer.adoc[Polling Consumer] >>>> which points to the latest eips. If camel-quarkus really intentionally >>>> depends on camel 3.11.x then it should be possible to build the partial >>>> website with only the 3.11.x versions, but I get lots of errors like >>>> >>>> [ERROR] [12:44:05.727] ERROR (asciidoctor): target of xref not found: >>>> latest@components:eips:polling-consumer.adoc >>>> [ERROR] file: >>>> docs/components/modules/ROOT/pages/beanstalk-component.adoc >>>> [ERROR] source: https://github.com/apache/camel.git (refname: >>>> camel-3.11.x, start path: docs/components) >>>> >>>> I think there are 22 such usages, involving all links in the `components` >>>> component to eips. >>>> >>>> If we agree this is a problem I’ll prepare some PRs for the affected >>>> branches (presumably at least main and 3.11.x) >>>> >>>> >>>> David Jencks >>>> >>>> side note: The camel-quarkus index page (both latest and 2.0.0) says >>>> Camel Quarkus also takes advantage of the many performance improvements >>>> made in Camel 3, which results in a lower memory footprint, less reliance >>>> on reflection (which is good for native application support) and faster >>>> startup times. >>>> I’m bewildered by this, and want to know “compared with what?”. I also >>>> think it would be nice if there was an explanation of what is different >>>> between the latest and 2.0.0 versions of camel-quarkus, right on the index >>>> page. >>>> >>>> >> > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com <http://davsclaus.com/> @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 > <https://www.manning.com/ibsen2>
