The names of the recipes correspond to the Camel version they support, formatted as [major].[minor].yaml. To migrate from version X.Y to version A.B, apply all recipes with versions greater than X.Y and less than A.B. For example, to migrate from version 3.8 to 4.4, you need to apply the recipes 4.0.yaml and 4.4.yaml.

Special recipes latest.yaml and 4.10LTS.yaml (or other lts version in the future) can be used for migration to the latest version.

How to run from cmd

To upgrade to the latest version of Camel, you can execute the following script:

To upgrade to the latest version of Camel 4.10 (LTS), you can execute the following script:

To upgrade to the latest version of Camel 4.18 (LTS), you can execute the following script:

To upgrade a Camel Spring Boot application to the latest version:

To upgrade a Camel Spring Boot application to the 4.18 LTS (staying on Spring Boot 3.x):

To apply specific recipes you can use the following script:

Warning

This project is not meant for migration of an application based on Camel-Quarkus. Use Quakus migration guide instead.

JUnit testing

Several migration paths to different versions must be covered by the tests. Therefore, the project uses the maven-dependency-plugin to download various versions of certain libraries.

Libraries are not packed into the installed jar.

Test jar

Project installs also test classes into a test-jar artifact. This allows other projects (like quarkus-updates) to reuse the tests.

Releasing

This project is released as standard Apache Camel module.

⚠️ Check that release notes are up-to-date!

⚠️ Check that the following versions are up-to-date!

Note	The `camel-latest-version` property is automatically verified by the test suite (`LatestCamelVersionTest`) to match the highest version recipe file. If you add a new version recipe (e.g., `4.21.yaml`), the test will fail until you update the property.

Check that everything is alright and run:

Then perform the release:

Go to https://repository.apache.org/ and close the staging repository.

A URL will be generated for the repository, like: https://repository.apache.org/content/repositories/orgapachecamel-xxxx. The URL needs to be communicated during the voting process.

Now run:

You’ll be requested to insert the password to unlock the secret key to sign the artifacts and after uploading to nexus dev repository.

You could verify the result at the following URL:

https://dist.apache.org/repos/dist/dev/camel/camel-upgrade-recipes/<$CAMEL_UPGRADE_RECIPES_VERSION>;

Send an email to dev mailing list to start the vote.

Post Release

Once the vote for the release has been completed, you need to send the Vote Result mail to mailing list.

Now, you’ll need to release the artifacts from Apache staging repositories to Apache releases repository.

To do this you’ll need to access the Apache Nexus Server.

You’ll need then to promote the release from dist/dev location to dist/release location.

There is an handy script for this:

Now run:

When done, release the staging repository.

To do this you’ll need to access https://repository.apache.org/#stagingRepositories. Select proper staging repository and click release.

Cancelling

If the vote email was already sent, send a cancelling vote email. (example)

All changes done during the releasing have to be reverted manually:

Staging repository has to be dropped in https://repository.apache.org/#stagingRepositories
Both tag and release in github have to be deleted
Project version has to be reverted to the value before the release was started. (example commit)
Dev folder (example) has to be deleted via svn. See example commands below.

Applying OpenRewrite best practices

On pull requests, a GitHub Action is run to apply OpenRewrite best practices to the codebase. To minimize changes, you can run the following command locally to apply the same best practices: