RELEASE.md

March 28, 2025 ยท View on GitHub

Releases

Creating a new minor release

  1. Create release branch. The release branch name follows the pattern release/vX.Y.x, where X is the major version and Y is the new minor version. For example, when releasing a new v1.0.0 version, we'd create the release branch release/v1.0.x.
git checkout main
git pull origin main
git checkout -b release/v1.0.x
git push origin release/v1.0.x

  1. Update the change_in directives for the new release branch. There's an easy one-liner for that here. Since the release branch is protected, you'll need a PR for updating it with those changes.

  2. Start the ephemeral environment and run the E2Es on it. If the E2Es are not green, you need to fix them before proceeding.

  3. If E2Es are green, tag the release branch:

git checkout release/v1.0.x
git pull origin release/v1.0.x
git tag v1.0.0
git push origin v1.0.0

  1. Use the "Generate Helm chart" and "Release" promotions to create a new Helm chart and push it to a release in GitHub.

  2. After the release is published, generate the changelog for it and add it in the release description. Details for that are here.

Update change_in directives

You can use yq to update all change_in directives in the Semaphore YAML:

yq e -i '(.blocks.[].run.when) |= (. | sub("main", "release/v1.0.x"))' .semaphore/semaphore.yml

Generate changelog

Use git-cliff, using the previous release tag and this one:

git-cliff --github-repo "semaphoreio/semaphore" -c cliff.toml <previous-version>..v1.0.0

A few notes here:

  • You will need to review the changes and make sure they are appropriate. We are not enforcing conventional commits yet, so some changes might not be included.
  • If there are breaking changes, include a section at the beginning of the changelog detailing the breaking changes.
  • If the upgrade process requires any attention, include a section for it as well.