Camel 4.22 and 4.18 side by side

Weik.io 2026.2 ships two Camel lines, 4.18.5 and 4.22.1, and each integration chooses the one it runs on. Integrations on both lines run next to each other on the same agents, so a team can move its integrations to a newer Camel one at a time and test each move in devtest before it reaches production.

Choosing the line

An integration sets its Camel line in integration.yaml:

name: erp-invoice-export
version: 1.1.0
camelVersion: "4.22.1"

A folder without integration.yaml can name it in application.properties instead, with the same key that Camel JBang uses, so a local run gets the same line:

camel.jbang.camel-version=4.18.5

An integration that sets no line gets the installation's default, which a platform admin sets with weikio settings set --default-camel-version. A range such as 4.22.x resolves to the newest line the installation lists in that minor version, so its next version is built on a newer patch of 4.22 once the installation adds one:

name: invoice-archive
version: 1.4.2
camelVersion: "4.22.x"

weikio get camel-lines lists the lines the installation allows, with the kamelet catalog pinned to each line, the digest of the launcher that builds it and the Java version it needs, and it marks the default.

What follows the line

The build runs the tools of the integration's own line. On 4.22.1 it validates the routes with camel validate, so a malformed route fails during the apply with Camel's own message. It then resolves the dependencies with camel dependency copy for that line and stores the jars of the version at the hub.

The kamelet catalog follows the line too. A kamelet name resolves first to the integration's own folder, then to the five kamelets of the platform, then to the project's shared kamelets and last to the catalog of the integration's line, so an integration on 4.18.5 gets the 4.18 catalog's kamelets and one on 4.22.1 gets the 4.22 catalog's.

On the agent, each line starts its Java processes from a shared snapshot of the classes every integration of that line loads. The processes of one line share those pages, and an integration starts in about 0.38 seconds instead of 0.63.

Moving an integration to 4.22

Change camelVersion in integration.yaml, publish the folder as a new version and deploy it to devtest:

$ weikio apply -f ./finance/erp-invoice-export --bump minor
Target: https://hub.example, project finance (from finance/project.yaml)
Uploading 2/9 files, building...
integration finance/erp-invoice-export updated (version 1.1.0, built in 17.3 s)
integration.yaml updated to 1.1.0

Nothing new is running yet. To run it:
  weikio deploy -f ./finance/erp-invoice-export --env devtest

weikio get versions lists every version with its Camel line in the CAMEL column and the environments it's deployed in, so you see which line each environment runs.

When the new version has run in devtest, weikio promote moves it to production without a new build. If something on the new line misbehaves there, weikio rollback points production back at the previous version, which runs on its own line with its own jars. weikio describe version prints the exact jar set of a version, months after it was built.

What comes next

Weik.io 2026.2.3 focuses on Camel versions, with more lines side by side, such as a third line next to 4.18 and 4.22. Where Weik.io is going lists what the next releases bring.