chore(doc): Add 1.7.x documentation

[astefanutti]

Fixes #2753, in combination with apache/camel-k-runtime#754.

Release Note

NONE

[djencks]

Is this correct, or should it be 3.13.x? The original plan was to remove the 3.12.x docs a couple days ago, until we found out that the current camel-quarkus released version actually depends on 3.12.x. If 3.12.x is correct for camel-k, it will mean we keep the camel 3.12.x docs around until the next release of camel-k which will presumably depend on a later version of camel. This is totally fine and appropriate if it accurately describes the dependencies between the projects.
I also wonder if 'next' is the appropriate value in the camel-k main branch.
I would really like a clear description in the docs somewhere of how each subproject version relates to a main camel version.

[astefanutti]

Is this correct, or should it be 3.13.x? The original plan was to remove the 3.12.x docs a couple days ago, until we found out that the current camel-quarkus released version actually depends on 3.12.x. If 3.12.x is correct for camel-k, it will mean we keep the camel 3.12.x docs around until the next release of camel-k which will presumably depend on a later version of camel. This is totally fine and appropriate if it accurately describes the dependencies between the projects.

I think it is 3.12.x, as Camel K also depends on that Camel Quarkus version:

https://github.com/apache/camel-k-runtime/blob/eb37ecbe7a829f4a09dc5e9f5ebc8b840d936f0b/pom.xml#L41

I also wonder if 'next' is the appropriate value in the camel-k main branch.

That's a good question. Currently we plan to depend on 3.13.x, but that may be too early to make a decision.

[djencks]

There may be a more complicated network of dependencies, that might lead to an inconsistent result, but if you follow the path from camel-k 'next' to camel-quarkus 'next' to camel, you will end up currently, I think, at 3.13.x. I can't think of an automated way of syncing these versions across projects.

[astefanutti]

Right. At some point, the next versions have to be changed to the actual versions, but I'm not sure that decision can be automated, or if there is a better process.

[djencks]

Looks good! Is there also a camel-website PR?

[astefanutti]

Looks good! Is there also a camel-website PR?

Ah no, I naively though this was it. Would you have a pointer, or I'll try to find my way out :)

[djencks]

The camel-website PR needs to modify this part of antora-playbook.yml:

    - url: https://github.com/apache/camel-k.git
      branches:
        - main
        - release-1.6.x
        - release-1.4.x
      start_path: docs

    - url: https://github.com/apache/camel-k-runtime.git
      branches:
        - main
        - release-1.9.x
      start_path: docs

You at least need to add the branches for camel-k 1.7.x and camel-k-runtime 1.10.x and if appropriate remove some earlier branches. After you make the PR there will eventually be a preview on netlify so you can check it all looks right. I actually start with a camel-website PR that points to the branches I'm modifying in the projects, in this case it would be this PR branch and the camel-k-runtime PR branch, and check it looks good before merging the non-website PRs: that way I can fix problems in the content PRs before merging them. I'm not sure that's really necessary here, but it is safer.

[astefanutti]

@djencks thanks a lot, I've just created apache/camel-website#680. There is also the dependency on the Kamelets catalog, that I wonder how it should materialise into the documentation:

camel-k/script/Makefile

Lines 59 to 62 in 119c1e0

	# Define here the repo containing the default Kamelet catalog (if any)
	KAMELET_CATALOG_REPO := https://github.com/apache/camel-kamelets.git
	# Optional branch for the default Kamelet catalog (change this to a tag before release)
	KAMELET_CATALOG_REPO_BRANCH := v0.5.0

[astefanutti]

You at least need to add the branches for camel-k 1.7.x and camel-k-runtime 1.10.x and if appropriate remove some earlier branches. After you make the PR there will eventually be a preview on netlify so you can check it all looks right. I actually start with a camel-website PR that points to the branches I'm modifying in the projects, in this case it would be this PR branch and the camel-k-runtime PR branch, and check it looks good before merging the non-website PRs: that way I can fix problems in the content PRs before merging them. I'm not sure that's really necessary here, but it is safer.

It seems from what I understand of the build error from apache/camel-website#680, that this PR has to be merged first to fix the Website PR build.

[zregvart]

It seems from what I understand of the build error from apache/camel-website#680, that this PR has to be merged first to fix the Website PR build.

Yup, Antora can't build components of same version containing the same files. So this needs to be merged first and then the apache/camel-website#680 should pass build/checks.

[astefanutti]

Yup, Antora can't build components of same version containing the same files. So this needs to be merged first and then the apache/camel-website#680 should pass build/checks.

Thanks for the confirmation. Let me merge this then.