= Releasing Apache Camel K

This procedure describes all the steps required to release a new version of Apache Camel K.
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.

[[releasing-camel-kamelets]]
== Releasing Camel Kamelets

The https://github.com/apache/camel-kamelets[Camel Kamelets] repository contains some artifacts that need to be pushed into Maven together
with a Camel K release.

Follow instructions on https://github.com/apache/camel-kamelets[Camel Kamelets] for the commands needed to release it.

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.

The source code for the created tag, with sha512sum and signature need to be copied in the Apache dev SVN at https://dist.apache.org/repos/dist/dev/camel/camel-kamelets/<version>.

Commit all files to the SVN.

Voting can start for camel-kamelets, or a combined vote with camel-k can be started later.

[[releasing-camel-k-runtime]]
== Releasing Camel K Runtime

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. For this reason, it's common to release the runtime artifacts together with a release of Camel K.
To avoid depending on snapshots, camel-k-runtime can be also released independently.

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.

To prepare a release and check problems:
```
./mvnw release:prepare -DdryRun -Prelease
```

Check the signatures of the files, then clean and prepare the actual release:

```
./mvnw release:clean -Prelease
./mvnw release:prepare -Prelease
```

Then perform the release:

```
./mvnw release:perform -Prelease
```

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.


The apache-camel-k-runtime-<version>-source-release.zip file present in path `/org/apache/camel/k/apache-camel-k-runtime/<version>/` (and sha512 sum, if present) will need to be copied in the Apache dev SVN at https://dist.apache.org/repos/dist/dev/camel/camel-k-runtime/<version>.

If the sha512 file is missing, one should be generated before committing to SVN.

Commit all files to the SVN.

Voting can start for camel-k-runtime, or a combined vote with camel-k can be started later.


[[releasing-camel-k]]
== Releasing Camel K

Releasing the Camel K main artifacts require some manual steps.

First thing is to checkout main branch and sync with upstream.

Next, the version of the runtime libraries to use need to be aligned in the Makefile (use the just released camel-k-runtime version if available).

The following tasks need to be done:

- Align `KAMELET_CATALOG_REPO_BRANCH` in Makefile to latest released tag of the camel-kamelets repository
- Align `RUNTIME_VERSION` in Makefile to latest runtime release
- Set `STAGING_RUNTIME_REPO` to the URL of the staging repo (if using a staged camel-k-runtime version)
- Ensure `LAST_RELEASED_VERSION` points to latest released version of Camel K

```
make clean codegen set-version build-resources check-licenses
```

Rebuild auto-generated data, including trait info:

```
make generate
```

Remove all snapshot files in the `/resources` directory, then run again:
```
# After removing snapshots from /resources
make clean build-resources
```

Run build and basic tests:
```
make
```

Sync the main branch (with your changes) with upstream.

```
git add *
git commit -m "preparing for next release"
# assuming write permissions
git push upstream main
```

Now the release on staging can be executed.

Change the version on Makefile to next version of camel-k (usually, just remove '-SNAPSHOT' from the version)
```
# after removing '-SNAPSHOT' from current VERSION in makefile
make release-staging
```

Binary files will be generated and put in the project root directory, including examples.
All those files should be put in the corresponding directory of the camel-k dev SVN at https://dist.apache.org/repos/dist/dev/camel/camel-k/<version>.

Sources are not produced directly by the scripts, but since the procedure is creating a tag, the source code in tar.gz format can be downloaded from Github
at: https://github.com/apache/camel-k/releases

After copying all the files to the dev SVN, a `sign.sh` script in the parent directory can be used to sign all the uploaded artifacts:

```
./sign.sh <version> <gpg_pass>
```

Commit all files to the SVN.

A docker image `camelk/camel-k:<version>` will be pushed to the staging organization (`camelk`, not `apache`).


[[testing]]
== Do some testing

A combined release can be immediately tested with the following install command:

```
kamel install --operator-image=camelk/camel-k:$CAMEL_K_VERSION --maven-repository=https://repository.apache.org/content/repositories/orgapachecamel-$APACHE_NEXUS_RUNTIME_REPO_ID
```


[[release-notes]]
== Release notes

Release notes can be generated with:

```
# previous version released on same branch, e.g. 1.8.0
export PREV=a.b.c
# current version to be released, e.g. 1.8.1
export CUR=x.y.z
# Branch where both tags are present
export BRANCH=main
# Personal access Token for accessing Github API
export GITHUB_TOKEN=token
# Run the release-notes command
./script/gen_release_notes.sh $PREV $CUR $BRANCH
```

A `release-notes.md` file is generated and can be attached to the release github issue for reference.

[[documentation]]
== Documentation updates

In order that the newly released versions of camel-k and camel-k-runtime appear in the Camel website, follow these steps:

. In camel-k `docs/antora.yml`:
.. Set the `version` appropriately, e.g. `1.7.x`
.. Remove the `prerelease` and `display_version`.
.. Set the `asciidoc.attributes.camel-version` to the appropriate released camel docs version, e.g. `3.12.x`.
. In the camel-k-runtime corresponding to the camel-k release `docs/antora.yml` set the `version` to the same value as in step 1.a.
. After the vote has passed, update the camel-website `antora-playbook.yml`
`content.sources` section for camel-k and camel-k-runtime to use the newly released versions, replacing the previous released version.

NOTE: this needs work, 1.6.x doesn't appear to have a corresponding camel-k-runtime
[source,yaml]
----
    - url: https://github.com/apache/camel-k.git
      branches:
        - main
#        Release-1.6.x does not work because there is no corresponding camel-k-runtime version for languages.
#        - release-1.6.x
        - release-1.4.x
      start_path: docs

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

[[voting]]
== Voting

An email should be sent to dev@camel.apache.org asking to test the staged artifacts. Voting will be left open for at least 72 hours.

[[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.

Republish docker image in the Apache org on Docker Hub:

```
# assuming logged in to docker hub
docker pull camelk/camel-k:$VERSION
docker tag camelk/camel-k:$VERSION apache/camel-k:$VERSION
docker push apache/camel-k:$VERSION
```

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.

The same should be done for camel-kamelets and camel-k-runtime in case of combined vote.

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
after an installation done with a simple `kamel install`).
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.

Download section on the website needs to be put in sync to display the new release.
Checkout the website and put an entry under `content/releases/k` with the version of the new release (copy the last release as template).
The milestone field in the release doc is the Github id for the milestone (e.g. for v1.4.1, the milestone is 22).

[[post-release]]
== Post Release

=== Operator Hub

The https://github.com/k8s-operatorhub/community-operators/[OperatorHub] downstream channel should be synced to publish the latest version
of Camel K, so that it can be easily installed on platforms that support Operator Hub.

The https://github.com/redhat-openshift-ecosystem/community-operators-prod/[Embedded OperatorHub in OpenShift and OKD] downstream channel should be synced to publish the latest version
of Camel K, so that it can be easily installed on OpenShift and OKD.

You can create the bundle using the `make bundle` command.

Once `make bundle` has been executed, you can run:

```
./script/prepare-operators.sh <version_just_released>
```

You'll get two different folders in the bundle folder
- k8s-operators
- openshift-ecosystem

In both the directories you'll have a folder with the version number specified in the command line.

The content of these folders is exactly what you need as base to create a PR for https://github.com/k8s-operatorhub/community-operators/[OperatorHub] and https://github.com/redhat-openshift-ecosystem/community-operators-prod/[Embedded OperatorHub in OpenShift and OKD].

=== Helm

An helm chart must be generated with the new version.

First update the chart version in the `Chart.yaml` file under the `/helm` section, setting a new chart release.

From the main branch:

```
./script/set_version.sh <released-version>
make release-helm
```

Commit to the main branch the tar.gz file and the updated index that have been generated in `/docs/charts` and the updated `Chart.yaml`.

Wait for them to be available on https://hub.helm.sh/.

=== Homebrew

The https://brew.sh/[HomeBrew] formula for _kamel_ must be synced to download and build the latest version of https://github.com/apache/camel-k[Camel K], so it can be easily installed on _macOs_ and _Linux_ platforms.

To do so, the content of https://github.com/Homebrew/homebrew-core/blob/master/Formula/kamel.rb[homebrew-core/Formula/kamel.rb] _(the package definition)_ should be updated to point the latest release of https://github.com/apache/camel-k[Camel K].

More importantly the _tag_ and _revision_ section configuration should change for a new release e.g
```
  url "https://github.com/apache/camel-k.git",
    :tag      => "0.3.4",
    :revision => "c47fb2c85e89852f0fd111d1662f57917030ced5"
  head "https://github.com/apache/camel-k.git"
```

_P.S please note that the bottles are created using the https://docs.brew.sh/Brew-Test-Bot[Brew Test Bot]   https://docs.brew.sh/Bottles[ [1] ]._