= 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 https://github.com/apache/camel-k-runtime[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 https://github.com/apache/camel-quarkus[Camel Quarkus].

Follow the https://github.com/apache/camel/blob/main/docs/user-manual/modules/ROOT/pages/release-guide.adoc[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 https://cwiki.apache.org/confluence/display/PEGASUS/Configure+GPG+key[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 https://infra.apache.org/publishing-maven-artifacts.html[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. Consider if you're about to release from `main` branch (generally a new major or minor version) or from a `release` branch (when you're about to release a patch version). In the latter case, you need to checkout to the proper release branch, ie `git checkout release-1.17.x`.

When you're in the project directory, 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 -Prelease
./mvnw 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 https://gitbox.apache.org[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>
```

[[testing]]
== 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]]
== 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]]
== 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]]
== Post release process

If you've released a major or a minor version, you may want to create a new `release-<major>.<minor>.x` branch that will be used for patch development. Accordingly, you can bump the version on `main` branch. 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.