From 11d5d769805c0a1f1c4767c09ec69564c21ce6ca Mon Sep 17 00:00:00 2001 From: Paolo Patierno Date: Tue, 31 Dec 2024 10:54:31 +0100 Subject: [PATCH] Updated release documentation (#10999) Signed-off-by: Paolo Patierno --- development-docs/RELEASE.md | 47 +++++++++++++++++++++---------------- 1 file changed, 27 insertions(+), 20 deletions(-) diff --git a/development-docs/RELEASE.md b/development-docs/RELEASE.md index 526e10e9c2e..f61295b0482 100644 --- a/development-docs/RELEASE.md +++ b/development-docs/RELEASE.md @@ -6,41 +6,39 @@ * Set version of the main Maven projects (`topic-operator` and `cluster-operator`) to `RELEASE_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` target will not build the Docker images - they should be built and pushed automatically by the Azure Pipelines 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: -1. Create a release branch +1. Create a release branch starting from the `main` one. The new release branch has to be named like `release-..x`, for example `release-0.45.x` to be used for all patch releases for the 0.45. 2. 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 to `0.6.0-SNAPSHOT` run: `make NEXT_VERSION=0.6.0-SNAPSHOT next_version`. - * Update the product version in `attributes.adoc` to the next version + * Update the versions to the next SNAPSHOT version using the `next_version` `make` target. For example to update the next version to `0.46.0-SNAPSHOT` run: `NEXT_VERSION=0.46.0-SNAPSHOT make next_version`. + * Update the product version in the `documentation/shared/attributes.adoc` file to the next version by setting the `ProductVersion` variable * Add a header for the new release to the `CHANGELOG.md` file - -3. Run `make clean` -4. 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`) -5. Run `make release` - * This will automatically update all files in `packaging/` as well as in `install/`, `example/` and `helm-chart/` +3. Move to the release branch and run `make clean` +4. Use the `RELEASE_VERSION` environment variable to set the desired version + * Use always the GA version here (e.g. `0.45.0`) and not the RC version (e.g `0.45.0-rc1`) +5. Run `RELEASE_VERSION= make release`, for example `RELEASE_VERSION=0.45.0 make release` + * This will automatically update several `pom.xml` files and all files in `packaging/`, `install/`, `example/` and `helm-chart/` folders. 6. Update the checksums for released files in `.checksums` in the release branch - * Use the Make commands `make checksum_examples`, `make checksum_install`, and `make checksum_helm` + * Use the Make commands `make checksum_examples`, `make checksum_install`, and `make checksum_helm` to generate the new checksums * Updated the checksums in the `.checksums` file in the root directory of the GitHub repository -7. Commit the changes to the existing files (do not add the newly created top level TAR.GZ, ZIP archives or .yaml files into Git) +7. Commit the changes to the existing files (do not add the newly created top level tar.gz, zip archives or .yaml files named like `strimzi-*` into Git) 8. Push the changes to the release branch on GitHub 9. 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) 10. 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 or `0.6.0` GA releases) + * Set the desired release version (e.g. `0.45.0-rc1` for RCs or `0.45.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) 11. Once the release build is complete: - * Download the release artifacts + * Download the release artifacts (binary, documentation and sbom) * Check the images pushed to Quay.io * Mark the build in the Azure Pipelines UI to be retained forever 12. 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. `0.45.0-rc1` 13. _(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 @@ -48,7 +46,7 @@ The release process should normally look like this: * Create new directories `docs/operators/` and `docs/operators//full` in the website repository * Copy files from the operators repository `documentation/htmlnoheader` to `docs/operators/` in the website repository * Copy files from the operators repository `documentation/html` to `docs/operators//full` in the website repository - * Create new files `contributing.md`, `deploying.md`, `overview.md`, `quickstart.md`, and `using.md` in `docs/operators/` - the content of these files should be the same as for older versions, so you can copy them and update the version number. + * Create new files `configuring.md`, `deploying.md` and `overview.md` in `docs/operators/` - 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` and `docs/operators/latest/full` (keep the `*.md` files) * Copy files from the operators repository `documentation/htmlnoheader` to `docs/operators/latest` in the website repository * Copy files from the operators repository `documentation/html` to `docs/operators/latest/full` in the website repository @@ -58,15 +56,15 @@ The release process should normally look like this: ``` helm repo index --merge --url ``` - For example, for Strimzi 0.34.0 release, if you unpacked the release artifacts to `./strimzi-0.34.0-rc1/` and have the Strimzi website checkout in `strimzi.github.io/`, you would run: + For example, for Strimzi 0.45.0 release, if you unpacked the release artifacts to `./strimzi-0.45.0-rc1/` and have the Strimzi website checkout in `strimzi.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/ + helm repo index ./strimzi-0.45.0/ --merge ./strimzi.github.io/charts/index.yaml --url https://github.com/strimzi/strimzi-kafka-operator/releases/download/0.45.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 to `charts/index.yaml` on the website. 14. _(only for GA, not for RCs)_ On the `main` git branch of the repository: - * Update the `ProductVersion` variable in `documentation/using/shared/attributes.adoc` + * Update the `ProductVersion` variable in `documentation/shared/attributes.adoc` * Update the `install`, `examples` and `helm-chart` directories in the `main` branch with the newly released files * Update the checksums for released files in `.checksums` @@ -84,3 +82,12 @@ If you need to update the Kafka bridge to newer version, you should do it with f 1. Edit the `bridge.version` file and update it to contain the new Bridge version 2. Run `make bridge_version` to update the related files to the new version 3. Commit all modified files to Git and open a PR. + +## Running Azure System Tests pipelines + +After releasing a RC, we need to run the following System Tests pipelines: + +* help-acceptance +* upgrade +* regression (multiple times, one for each supported Kafka version) +* feature-gates-regression (multiple times, one for each supported Kafka version)