Skip to content

Latest commit

 

History

History
126 lines (100 loc) · 4.31 KB

RELEASE_PROCESS.md

File metadata and controls

126 lines (100 loc) · 4.31 KB
Raw

Release Process

This document outlines the release process for Interchain Security (ICS).

For details on ICS releases, see RELEASES.md.

Changelog

For PRs that are changing production code, please add a changelog entry in .changelog (for details, see contributing guidelines).

To manage and generate the changelog on ICS, we currently use unclog. Read the README.md in the unclog repo for instruction on how to install and use unclog.

Creating a new release branch

Unreleased changes are collected on main in .changelog/unreleased/. However, .changelog/ on main contains also existing releases (e.g., v3.2.0). Thus, when creating a new release branch (e.g., release/v3.3.x), the following steps are necessary:

  • create a new release branch, e.g., release/v3.3.x 
    git checkout main
git pull 
git checkout -b release/v3.3.x
  • delete all the sub-folders in .changelog/ except unreleased/ 
    find ./.changelog -mindepth 1 -maxdepth 1 -type d -not -name unreleased | xargs rm -r
  • replace the content of .changelog/epilogue.md with the following text 
    ## Previous Versions

[CHANGELOG of previous versions](https://github.com/cosmos/interchain-security/blob/main/CHANGELOG.md)
  • push the release branch upstream 
    git push

Cutting a new release

Before cutting a release candidate (e.g., v3.3.0-rc0), the following steps are necessary:

  • move to the release branch, e.g., release/v3.3.x 
    git checkout release/v3.3.x
  • move all entries in ".changelog/unreleased" to the release version, e.g., v3.3.0, i.e., 
    unclog release v3.3.0
    • unclog release requires an editor. This can be set either by configuring an $EDITOR environment variable or by manually specify an editor binary path via the --editor flag.
  • add the date as the summary of the release (unclog release requires adding a summary), e.g., 
    *December 5, 2023*
  • update CHANGELOG.md, i.e., 
    unclog build > CHANGELOG.md
  • open a PR (from this new created branch) against the release branch, e.g., release/v3.3.x

Now you can cut the release candidate, e.g., v3.3.0-rc0 (follow the Tagging Procedure).

Update the changelog on main

Once the final release is cut, the new changelog section must be added to main:

  • checkout a new branch from the main branch, i.e., 
    git checkout main
git pull 
git checkout -b <username>/backport_changelog
  • bring the new changelog section from the release branch into this branch, e.g., 
    git checkout release/v3.3.x .changelog/v3.3.0
  • remove duplicate entries that are both in .changelog/unreleased/ and the new changelog section, e.g., .changelog/v3.3.0
  • update CHANGELOG.md, i.e., 
    unclog build > CHANGELOG.md
  • open a PR (from this new created branch) against main

Tagging Procedure

Important: Always create tags from your local machine since all release tags should be signed and annotated.

The following steps are the default for tagging a specific branch commit using git on your local machine. Usually, release branches are labeled release/v*:

Ensure you have checked out the commit you wish to tag and then do:

git pull --tags
git tag -s v3.2.0 -m v3.2.0
git push origin v3.2.0

To re-create a tag:

# delete a tag locally
git tag -d v3.2.0

# push the deletion to the remote
git push --delete origin v3.2.0

# redo the tagging
git tag -s v3.2.0 -m v3.2.0
git push origin v3.2.0

For final releases, once the tag is created, use the GitHub interface to create a release. Note that this is not necessary for release candidates.