| = 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. |
| |
| Now run: |
| |
| ``` |
| cd release-utils/scripts/ |
| ./upload-sources.sh <released_version> <released_version> |
| ``` |
| |
| Voting can start for camel-k-runtime, or a combined vote with camel-k can be started later. |
| |
| [[releasing-camel-k-crds]] |
| == Releasing Camel K CRD dependency |
| |
| Camel K ships a Maven dependency containing the CRDs required in Kubernetes. This dependency is available in `/java/` directory and has to be released togheter with Camel K. The process below is the same used for Camel K Runtime. |
| |
| 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: |
| ``` |
| ./java/mvnw release:prepare -DdryRun -Prelease |
| ``` |
| |
| Check the signatures of the files, then clean and prepare the actual release: |
| |
| ``` |
| ./java/mvnw release:clean -Prelease |
| ./java/mvnw release:prepare -Prelease |
| ``` |
| |
| Then perform the release: |
| |
| ``` |
| ./java/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. |
| |
| [[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_TAG` 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 |
| ``` |
| |
| If you are on an active branch and you're going to release on it the command will be |
| |
| Sync the main branch (with your changes) with upstream. |
| |
| ``` |
| git add * |
| git commit -m "preparing for next release" |
| # assuming write permissions |
| git push upstream <branch_name> |
| ``` |
| |
| 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. |
| |
| Now run: |
| |
| ``` |
| cd release-utils/scripts/ |
| ./upload-sources.sh <released_version> <released_version> |
| ``` |
| |
| This will upload the sources, client and examples to the dist/dev repository in ASF. |
| |
| 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 |
| |
| The version of Camel K and the main related dependencies are scraped automatically in a Github Action. You only need to provide the LTS parameter in the related `release` branch, when the release is marked as LTS (such as in https://github.com/apache/camel-k/blob/f15124949e43bb859d07f555b9e510956d6ed823/docs/antora.yml#L30) |
| |
| 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. |
| |
| [[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. |
| |
| Camel-kamelets, camel-k-runtime and camel-k contains 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 |
| 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] ]._ |
| |
| === Bump to next version |
| |
| Once the release process is complete, we must prepare the configuration for next version. In order to do so, please run the following: |
| ``` |
| make bump VERSION=<new-version> LAST_RELEASED_VERSION=<replace-version> |
| git commit -m "chore: bump next version to <new-version>" |
| git push upstream main |
| ``` |
| Where <new-version> represents the new version you want to bump and <replace-version> the version that was previously released. |
| |
| Note: this action should also replace automatically the oldest nightly release Github Action with the newest one just created. |
| |
| You will also need to update the `docs/antora.yml` configuration in order to provide the proper versions for the upcoming release in `main` branch. |