Project: Jaeger (Observability and Analysis / Observability)
File: RELEASE.md

Create a PR "Prepare release X.Y.Z" against main or maintenance branch () by updating CHANGELOG.md to include: A new section with the header `<X.Y.Z> (YYYY-MM-DD)` (copy the template at the top) A curated list of notable changes and links to PRs. Do not simply dump git log, select the changes that affect the users. To obtain the list of all changes run `make changelog` or use `scripts/release-notes.py`. The section can be split into sub-section if necessary, e.g. UI Changes, Backend Changes, Bug Fixes, etc. If the jaeger-ui submodule has changes cut a new release and also upgrade the submodule versions then commit, for example: ``` git submodule init git submodule update cd jaeger-ui git checkout main git pull git checkout {new_version} //e.g. v1.5.0 ``` If there are no changes, indicate this with "No changes" (). Rotate the below release managers table placing yourself at the bottom. The date should be the first Wednesday of the month. After the PR is merged, create a release on Github: Automated: `make draft-release` Manual: Title "Release X.Y.Z" Tag `vX.Y.Z` (note the `v` prefix) and choose appropriate branch Copy the new CHANGELOG.md section into the release notes Extra: GitHub has a button "generate release notes". Those are not formatted as we want, but it has a nice feature of explicitly listing first-time contributors. Before doing the previous step, you can click that button and then remove everything except the New Contributors section. Change the header to `### New Contributors`, then copy the main changelog above it. . The release tag will trigger a build of the docker images. Since forks don't have jaegertracingbot dockerhub token, they can never publish images to jaegertracing organisation. Check the images are available on . For monitoring and troubleshooting, refer to the . for the new version in . Check redirects to the new documentation release version URL. For monitoring and troubleshooting, refer to the . Announce the release on the , , and . Maintenance branches should follow naming convention: `release-major.minor` (e.g.`release-1.8`). Sometimes we need to do a patch release, e.g. to fix a newly introduced

If the main branch already contains newer changes, it is recommended that a patch release is done from a version branch. Find the commit in `main` for the release you want to patch (e.g., `a49094c2` for v1.34.0). `git checkout ${commit}; git checkout -b ${branch-name}`. The branch name should be in the form `release-major.minor`, e.g., `release-1.34`. Push the branch to the upstream repository. Apply fixes to the branch. The recommended way is to merge the fixes into `main` first and then cherry-pick them into the version branch (e.g., `git cherry-pick c733708c` for the fix going into `v1.34.1`). Follow the regular process for creating a release (except for the Documentation step). When creating a release on GitHub, pick the version branch when applying the new tag. Once the release tag is created, the `ci-release` workflow will kick in and deploy the artifacts for the patch release. Do not perform a new release of the documentation since the major.minor is not changing. The one change that may be useful is bumping the `binariesLatest` variable in the `config.toml` file (). A Release Manager is the person responsible for ensuring that a new version of Jaeger is released. This person will coordinate the required changes, including to the related components such as UI, IDL, and jaeger-lib and will address any problems that might happen during the release, making sure that the documentation above is correct. In order to ensure that knowledge about releasing Jaeger is spread among maintainers, we rotate the role of Release Manager among maintainers. Here are the release managers for future versions with the tentative release dates. The release dates are the first Wednesday of the month, and we might skip a release if not enough changes happened since the previous release. In such case, the next tentative release date is the first Wednesday of the subsequent month. | Version | Release Manager | Tentative release date | ||--|| | 1.58.0 | @pavolloffay | 5 June 2024 | | 1.59.0 | @joe-elliott | 3 July 2024 | | 1.60.0 | @jkowall | 7 August 2024 | | 1.61.0 | @yurishkuro | 3 September 2024 | | 1.62.0 | @albertteoh | 2 October 2024 |