Skip to content

Latest commit

 

History

History
166 lines (108 loc) · 8.08 KB

release.adoc

File metadata and controls

166 lines (108 loc) · 8.08 KB
Raw

Releasing Apache Camel K runtime

This procedure describes all the steps required to release a new version of Apache Camel K runtime dependency. It is not intended to be final, but rather a working document that needs to be updated when new requirements are found or the technical process changes.

The Camel K Runtime project is not a standalone project, it’s meant to be used with Camel K. However, since it depends on Camel Quarkus project, the release process is going to be independent and the versioning notation is going to be aligned with the one used by Camel Quarkus.

Follow the Camel release guide in order to setup the Maven environment and gpg for the release.

GPG key configuration

Here some quick notes about how to configure the GPG key (this will be required just once, tipycally the first time you do a release). If you’re on a Linux distribution, you should have gpg binary available: try with gpg --version. Once the binary is there you need to execute:

gpg --full-gen-key

This command will prompt a series of requests you’ll need to fill. Have a look at the procedure described in another Apache project page for more details.

Once you have created your key, it is convenient you add it to the KEYS file in root Camel K Runtime github:

gpg --list-sigs "pcongiusti@apache.org" >> KEYS && gpg --armor --export "pcongiusti@apache.org" >> KEYS

You also need to recover your fingerprint and copy to the https://id.apache.org account:

$ gpg --fingerprint

pub   rsa4096 2023-05-26 [SC]
      xyzz accc brrr dsad 1234  1234 1234 1234 1234 1234    <-- This is the fingerprint!
uid           [ultimate] Pasquale Congiusti (gpg key) <pcongiusti@apache.org>
sub   rsa4096 2023-05-26 [E]

Once this step is over, you will need to send your GPG key to certain serves used later when verifying the signed pushed artifacts:

$ gpg -k

pub   rsa4096 2023-05-26 [SC]
      1234123412341234123412341132132131312123            <-- This is the key you need!
uid           [ultimate] Pasquale Congiusti (gpg key) <pcongiusti@apache.org>
sub   rsa4096 2023-05-26 [E]

gpg --keyserver hkp://keyserver.ubuntu.com --send-keys 1234123412341234123412341132132131312123
gpg --keyserver hkp://keys.openpgp.org --send-keys 1234123412341234123412341132132131312123

Now you can proceed with the release.

Maven settings configuration

As you will be required to publish on Apache servers via Maven, you will need to configure properly your maven settings. You may provide plain text password to the local settings and later reference that settings at the last step of release process via -s parameter.

Release process

As the process will do git operations, it is advisable that you clone the Camel K Runtime repository to some new location (ie /tmp/) in order to avoid to conflict with any other development in progress. If you’re starting a major or a minor release version, you need to create the correspective release-a.b.x branch. It’s highly advisable not to release directly from main branch.

Create release branch from main branch

We have a script that simplify this process. As we do not only want to create and push a new branch, we also need to provide the CI tasks required for all the supported releases.

./scripts/release-branch.sh
Note
 you can run the script with -d option to dry run and evaluate the changes before pushing them to the repo.

Start the release process

You need to checkout to the proper release branch, ie git checkout release-1.17.x. You can start the release process.

To prepare a release and check problems:

./mvnw release:prepare -Prelease -DautoVersionSubmodules=true -DdryRun

During the process you will be requested to provide the final version you’re about to release (typically the same you’re working on but withouth SNAPSHOT) and the next one that will be started after. Once the process is over, check the signatures of the files, then clean and prepare the actual release:

./mvnw release:clean release:prepare -Prelease -Duser=<your Apache LDAP id> [-Dpassword=<your Apache LDAP pwd>] -Darguments=-DskipTests -DautoVersionSubmodules=true

You need to provide the user (and optionally password) of your Apache account. This is required as the procedure will log in to GitBox. If you do not provide the password, it will be prompted during the procedure and you’ll need to provide it when asked.

If the previous step was fine, you’re about to perform the last step of the release:

./mvnw release:perform -Prelease [-s path/to/your/settings.xml]

Once it’s over, go to https://repository.apache.org/ and close the staging repository: this is a process required to generate a URL for the repository, like: https://repository.apache.org/content/repositories/orgapachecamel-xxxx. The URL needs to be communicated during the voting process.

In order to upload sources and clients to the dist/dev repository in ASF you’ll need to execute:

cd release-utils/scripts/
./upload-sources.sh <released_version> <released_version>

Do some testing

In order to test the runtime, you can use any Camel K operator with version 2 onward (ideally, latest). When installing it, you need to provide the staging repository wich contains the Camel K runtime to be released.

kamel install --maven-repository=https://repository.apache.org/content/repositories/orgapachecamel-$APACHE_NEXUS_RUNTIME_REPO_ID
...
kamel run Test.java -t camel.runtime-version=<released_version>

Voting

All is in place for the release. Send an email to dev@camel.apache.org asking to test the staged artifacts. Voting will be left open for at least 72 hours. You can take a previous voting email as reference for your new communication.

Finalizing the release

After the voting is complete with success, the artifacts can be released.

Release the staging repository at: https://repository.apache.org. Artifacts committed on https://dist.apache.org/repos/dist/dev/ before the voting process need to be copied to the Apache dist repository on: https://dist.apache.org/repos/dist/release/camel.

Run a script to promote the release from dev to release

cd release-utils/scripts/
./promote-release.sh <released_version>

Wait for maven mirrors to sync the new artifacts. This can take more than 1 hour sometimes.

Binary files can be now released on Github, together with release notes generated in previous step. Files need to be uploaded manually to a new Github release.

Before announcing the release, a simple test should be done to verify that everything is in place (running a "Hello World" integration with the released runtime (kamel run Test.java -t camel.runtime-version=<released_version>). Do a simple final test.

The release can be now announced to dev@camel.apache.org and users@camel.apache.org.

A PMC member with access to the @ApacheCamel Twitter account should announce the release on Twitter as well.

Post release process

Documentation

For each release you need to create an entry in the release section of Camel website project: https://github.com/apache/camel-website/tree/main/content/releases/k-runtime - you can use any previous document as a reference.

Note
 the milestone is the github project milestone ID used to track the release.

Bump to next version

You can bump the version on main branch if there is already a new development version available for next major or minor. This has to be aligned to the next Camel Quarkus version you’re willing to support for Camel K Runtime:

./script/bump.sh --camel-quarkus 2.16.0
# you need to git commit & push afterwards

The project has an automatic action (./script/sync_cq.sh) running every night by Github Actions which is in charge to align the set of dependencies required by Camel Quarkus, according to the release.