Skip to content

RELEASE_CHECKLIST.md

Latest commit

 

History

History
137 lines (119 loc) · 14.5 KB

RELEASE_CHECKLIST.md

File metadata and controls

137 lines (119 loc) · 14.5 KB
Raw

✅ Release Checklist (vX.Y.Z[-rcN])

Labels

If an item should be executed only for a specific release type, it is labeled with:

  • execute ONLY when releasing a Release Candidate
  • execute ONLY when releasing a Final Release
  • do NOT execute when releasing a Patch Release

Otherwise, it means a step should be executed for ALL release types.

Before the release

This section covers tasks to be done ahead of the release.

  • Verify you have access to all the services and tools required for the release
    • GPG signature configured in local git and in GitHub
    • docker installed on your system
    • npm installed on your system
    • kubo checked out under $(go env GOPATH)/src/github.com/ipfs/kubo
      • you can also symlink your clone to the expected location by running mkdir -p $(go env GOPATH)/src/github.com/ipfs && ln -s $(pwd) $(go env GOPATH)/src/github.com/ipfs/kubo
  • Upgrade Go used in CI to the latest patch release available at https://go.dev/dl/

The release

This section covers tasks to be done during each release.

1. Prepare release branch

  • Prepare the release branch and update version numbers accordingly
    • create a new branch release-vX.Y.Z
      • use master as base if Z == 0
      • use release as base if Z > 0
    • update the CurrentVersionNumber in version.go in the master branch to vX.Y+1.0-dev (example)
    • update the CurrentVersionNumber in version.go in the release-vX.Y.Z branch to vX.Y.Z(-rcN) (example)
    • create a draft PR from release-vX.Y.Z to release (example)
    • Cherry-pick commits from master to the release-vX.Y.Z using git cherry-pick -x <commit> (example)
      • NOTE: cherry-picking with -x is important
    • Replace the Changelog and Contributors sections of the changelog with the stdout (do NOT copy the stderr) of ./bin/mkreleaselog.
      • NOTE: mkreleaselog expects your $GOPATH/src/github.com/ipfs/kubo to include latest commits from release-vX.Y.Z
    • verify all CI checks on the PR from release-vX.Y.Z to release are passing
    • Merge the PR from release-vX.Y.Z to release using the Create a merge commit
      • do NOT use Squash and merge nor Rebase and merge because we need to be able to sign the merge commit
      • do NOT delete the release-vX.Y.Z branch

2. Tag release

  • Create the release tag
    • ⚠️ NOTE: This is a dangerous operation! Go and Docker publishing are difficult to reverse! Have the release reviewer verify all the commands marked with !
    • tag the HEAD commit using git tag -s vX.Y.Z(-rcN) -m 'Prerelease X.Y.Z(-rcN)'
    • tag the HEAD commit of the release branch using git tag -s vX.Y.Z -m 'Release X.Y.Z'
    • ⚠️ verify the tag is signed and tied to the correct commit using git show vX.Y.Z(-rcN)
    • push the tag to GitHub using git push origin vX.Y.Z(-rcN)
      • ⚠️ do NOT use git push --tags because it pushes all your local tags

3. Publish

4. After Publishing

  • Merge the release branch back into master
    • Create a new branch merge-release-vX.Y.Z from release
    • Create the next ./docs/changelogs/vA.B.md and link to the new changelog from the ./CHANGELOG.md file
    • Create and merge a PR from merge-release-vX.Y.Z to master
      • ⚠️ do NOT use Squash and merge nor Rebase and merge because we need to be able to sign the merge commit
      • ⚠️ NOTE: make sure to ignore the changes to version.go (keep the -dev in master)
  • Update Kubo staging environment, see the Running Kubo tests on staging for details.
    • Test last release against the current RC
    • Test last release against the current one
  • Promote the release
  • Manually smoke-test the new version with IPFS Companion Browser Extension
  • Update Kubo in ipfs-desktop
    • check out ipfs/ipfs-desktop
    • run npm install
    • create a PR which updates package.json and package-lock.json
  • Update Kubo docs at docs.ipfs.tech:
  • Create a blog entry on blog.ipfs.tech
    • create a PR which adds a release note for the new Kubo version (example)
    • merge the PR
    • verify the blog entry was published
  • Create a dependency update PR
    • check out ipfs/kubo
    • go over direct dependencies from go.mod in the root directory (NOTE: do not run go get -u as it will upgrade indirect dependencies which may cause problems)
    • run make mod_tidy
    • create a PR which updates go.mod and go.sum
    • add the PR to the next release milestone
  • Create the next release issue
  • Close the release issue