Prepare Jaeger Release v1.74.0 / v2.11.0

[albertteoh]

UI Release

• Create and merge, per approval, a PR which preps the release (example).
  • The PR title should match the format "Prepare release v1.74.0"
    • Apply the label changelog:skip
  • CHANGELOG.md
    • Change the version of the current release from "Next (unreleased)" to "v1.74.0 (Month D, YYYY)",
      where "v1.74.0" is the semver for this release.
    • Run make changelog to list all changes since the last release.
    • Review all changes to determine how, if at all, any externally facing APIs are impacted.
      This includes, but is not limited to, the UI config and URL routes such as deep-linking
      and configuring the embedded mode.
    • If necessary, add a note detailing any impact to externally facing APIs.
  • Update packages/jaeger-ui/package.json#version to refer to the version being released.
• Create a GitHub release.
  • Automated (requires gh):
    • make draft-release

Backend Release

• Create a PR "Prepare release 1.74.0 / 2.11.0" against main or maintenance branch (example) by updating CHANGELOG.md to include:
  • A new section with the header 1.74.0 / 2.11.0 (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.
  • The section can be split into sub-section if necessary, e.g. UI Changes, Backend Changes, Bug Fixes, etc.
  • Then upgrade the submodule versions and finally commit. For example:

    git submodule init
    git submodule update
    pushd jaeger-ui
    git checkout main
    git pull
    git checkout {new_ui_version} # e.g. v1.74.0
    popd
    

    • If there are only dependency bumps, indicate this with "Dependencies upgrades only" (example).
    • If there are no changes, indicate this with "No changes" (example).
  • Rotate the below release managers table placing yourself at the bottom. The date should be the first Wednesday of the month.
  • Add label changelog:skip to the pull request.
• After the PR is merged, create new release tags:

  git checkout main
  git pull
  git tag v1... -s  # use the new version
  git tag v2... -s  # use the new version
  git push upstream v1... v2...
  

• Create a release on Github:
  • Automated:
    • make draft-release
• Go to Publish Release workflow on GitHub
  and run it manually using Run Workflow button on the right.
  • For monitoring and troubleshooting, open the logs of the workflow run from above URL.
  • Check the images are available on Docker Hub
    and binaries are uploaded to the releasehttps://github.com/jaegertracing/jaeger/releases.

Doc Release

Before creating a new release:

• Make sure all outstanding PRs for that version are merged to next-release directory.
• Make sure the actual Jaeger release is done and Docker images for the new version are published.

To create a new release:

• Manually trigger the Release workflow on GitHub. It will ask for v1 and v2 version numbers (same versions as in the main Jaeger repo), and create a pull request with the documentation changes.
• Approve and merge that pull request.
• Because the site is statically generated, the release is completed after the merge.

[yurishkuro]

@albertteoh I kicked off a rerun of Publish workflow, because it looks like it pushed the binaries but not Docker images and failed on out of disk space.

[albertteoh]

Checked that both jaeger binaries and documentation workflows completed successfully.
Spot-checked a few docker images and confirmed they have the latest tags.

Marking this as done.

Feel free to reopen if any other tasks need addressing.