make release
target can be used to create a release. Environment variable RELEASE_VERSION
(default value latest
) can be used to define the release version. The release
target will:
- Update all tags of Docker images to
RELEASE_VERSION
- Update documentation version to
RELEASE_VERSION
- Set version of the main Maven projects (
topic-operator
andcluster-operator
) toRELEASE_VERSION
- Create TAR.GZ and ZIP archives with the Kubernetes and OpenShift YAML files which can be used for deployment and documentation in HTML format.
The release
target will not build the Docker images - they should be built and pushed automatically by Travis CI when the release is tagged in the GitHub repository. It also doesn't deploy the Java artifacts anywhere. They are only used to create the Docker images.
The release process should normally look like this:
-
Create a release branch
-
On the
main
git branch of the repository:- Update the versions to the next SNAPSHOT version using the
next_version
make
target. For example to update the next version to0.6.0-SNAPSHOT
run:make NEXT_VERSION=0.6.0-SNAPSHOT next_version
. - Update the product version in
attributes.adoc
to the next version - Add a header for the new release to the
CHANGELOG.md
file
- Update the versions to the next SNAPSHOT version using the
-
Run
make clean
-
Export the desired version into the environment variable
RELEASE_VERSION
- Use always the GA version here (e.g.
0.6.0
) and not the RC version (0.6.0-rc1
)
- Use always the GA version here (e.g.
-
Run
make release
- This will automatically update all files in
packaging/
as well as ininstall/
,example/
andhelm-chart/
- This will automatically update all files in
-
Update the checksums for released files in
.checksums
in the release branch- Use the Make commands
make checksum_examples
,make checksum_install
, andmake checksum_helm
- Updated the checksums in the
.checksums
file in the root directory of the GitHub repository
- Use the Make commands
-
Commit the changes to the existing files (do not add the newly created top level TAR.GZ, ZIP archives or .yaml files into Git)
-
Push the changes to the release branch on GitHub
-
Wait for the CI to complete the build
- Once it completes, mark the build in the Azure Pipelines UI to be retained forever
- Download the build artifacts (Docs archives)
- Copy the build ID (from the URL in Azure Pipelines)
-
Run the
operators-release
pipeline manually in Azure pipelines- Select the release branch from the list
- Set the desired release version (e.g.
0.6.0-rc1
for RCs or0.6.0
GA releases) - Set the release suffix as
0
- Set the build ID to the build ID from previous step (For GA, this should be the build ID used for the last RC since there should be no changes)
-
Once the release build is complete:
- Download the release artifacts
- Check the images pushed to Quay.io
- Mark the build in the Azure Pipelines UI to be retained forever
-
Create a GitHub tag and release based on the release branch. Attach the release artifacts and docs as downloaded from the Azure pipelines.
- For RCs, the tag should be named with the RC suffix, e.g.
0.6.0-rc1
- For RCs, the tag should be named with the RC suffix, e.g.
-
(only for GA, not for RCs) Update the website
- Update the
_redirects
file to make sure the/install/latest
redirect points to the new release. - Update the
_data/releases.yaml
file to add new release - Update the documentation:
- Create new directories
docs/operators/<new-version>
anddocs/operators/<new-version>/full
in the website repository - Copy files from the operators repository
documentation/htmlnoheader
todocs/operators/<new-version>
in the website repository - Copy files from the operators repository
documentation/html
todocs/operators/<new-version>/full
in the website repository - Create new files
contributing.md
,deploying.md
,overview.md
,quickstart.md
, andusing.md
indocs/operators/<new-version>
- the content of these files should be the same as for older versions, so you can copy them and update the version number. - Delete the old HTML files and images from
docs/operators/latest
anddocs/operators/latest/full
(keep the*.md
files) - Copy files from the operators repository
documentation/htmlnoheader
todocs/operators/latest
in the website repository - Copy files from the operators repository
documentation/html
todocs/operators/latest/full
in the website repository
- Create new directories
- Add the Helm Chart repository
index.yaml
on our website:- Download the release artifacts from the CI pipeline and unpack them
- Use the
helm
command to add the new version to theindex.yaml
file:For example, for Strimzi 0.34.0 release, if you unpacked the release artifacts tohelm repo index <PATH_TO_THE_DIRECTORY_WITH_THE_ARTIFCATS> --merge <PATH_TO_THE_INDEX_YAML> --url <URL_OF_THE_GITHUB_RELEASE_PAGE>
./strimzi-0.34.0-rc1/
and have the Strimzi website checkout instrimzi.github.io/
, you would run:helm repo index ./strimzi-0.34.0/ --merge ./strimzi.github.io/charts/index.yaml --url https://github.com/strimzi/strimzi-kafka-operator/releases/download/0.34.0/
- The updated
index.yaml
will be generated in the directory with the artifacts. Verify the added data and the digest and if they are correct, copy it tocharts/index.yaml
on the website.
- Update the
-
(only for GA, not for RCs) On the
main
git branch of the repository:- Update the
ProductVersion
variable indocumentation/using/shared/attributes.adoc
- Update the
install
,examples
andhelm-chart
directories in themain
branch with the newly released files - Update the checksums for released files in
.checksums
- Update the
-
(only for GA, not for RCs) The maven artifacts (
api
module) will be automatically staged from Azure during the tag build. It has to be releases from Sonatype to get to the main Maven repositories. -
(only for GA, not for RCs) Update the Strimzi manifest files in Operator Hub community operators repository and submit a pull request upstream. Note: Instructions for this step need updating.
-
(only for GA, not for RCs) Add the new version to the
systemtest/src/test/resources/upgrade/BundleUpgrade.yaml
file for the upgrade tests -
(only for GA, not for RCs) Add the new version to the
systemtest/src/test/resources/upgrade/BundleDowngrade.yaml
file and remove the old one for the downgrade tests
The version of Strimzi Kafka Bridge is defined in the file ./bridge.version
.
Even the main
branch is using this fixed version and not the version build from the main
branch of Kafka Bridge.
If you need to update the Kafka bridge to newer version, you should do it with following steps:
- Edit the
bridge.version
file and update it to contain the new Bridge version - Run
make bridge_version
to update the related files to the new version - Commit all modified files to Git and open a PR.