This document describes the steps to be taken by maintainers who are issuing releases.
We aim to have as much of the process automated as possible, but there will always be certain (slightly mundane) tasks to that must be performed by a human with the right credentials (e.g. a maintainer) and this document has to be kept up to date in the event of any of these steps changing.
- Releases to be issued from the
main
branch only. - Semantic versioning is highly preferred: https://semver.org/
- Git tags are to be applied for commits that were chosen for release.
- Tag names must follow the pattern of
vX.Y.Z
for examplev2.0.0
The below document uses v1.1.3
as the example, when issuing a release you need to change this to whatever is the upcoming release that you are about to issue.
Hence the first step is to update (find and replace all) the document (no need to send a PR with those changes) so that the helper scripts are changed as well.
git fetch --all
git switch main
git rebase upstream/main
git push --force-with-lease
git checkout -b release-v1.1.3
yarn run configure
yarn lerna version 1.1.3 --ignore-scripts --conventional-commits --exact --git-remote upstream --message="chore(release): publish %s" --no-push --no-git-tag-version --no-ignore-changes --force-publish
yarn tools:bump-openapi-spec-dep-versions
yarn codegen
./tools/weaver-update-version.sh 1.1.3 .
./tools/go-gen-checksum.sh 1.1.3 .
-
Do note the
.
as the last parameter in last two commands. -
Double check that all of the package dependencies were updated from the previous version to the new one because lerna usually fails to do that for
devDependency
parts of the package.json files so you have to do this manually with search and replace through the entire repository...
The trick is to search for the previous release version within package.json files or just search for "@hyperledger/cactus-*" within the package.json files.
With VSCode you can do a project wide search & replace where:
- Make sure that regex based replacing is enabled on the VSCode search UI (top right corner of the search panel)
- You set the files to include to "package.json" (so that only files named package.json are included in the search)
- You set the search term to this to find the OLD versions (without the backticks if you are reading this in plain text)
@hyperledger/cactus-(.*): "1.1.2"
- You set the replacement term to this (so that it swaps the version numbers with the new one)
@hyperledger/cactus-$1: "1.1.3"
-
Also double check that the
"version": "?.?.?"
property has been updated in the package.json files all over the packages. -
update the lock file if necessary
$ yarn
-
Double check that the configure script still works (CI will fail without it anyway)
$ yarn configure
-
Double check that the changelog does not contain your fork's links instead of the upstream repo. You'll need to change this manually otherwise. For example, replace:
https://github.com/petermetz/cactus
withhttps://github.com/hyperledger/cactus
git add . && git commit --signoff --gpg-sign --message="chore(release): publish v1.1.3"
git push --set-upstream upstream release-v1.1.3
- Do a merge freeze
- Unfreeze the specific pull request that you just opened for the release issuance
- Wait for the PR to be approved as per standard governance rules
- Execute these commands (assuming your fork's git remote is
origin
and the official Hyperledger repo's isupstream
)
git fetch --all
git switch main
git rebase upstream/main
git merge --ff-only upstream/release-v1.1.3
git push upstream
git push origin
git tag -s -a "v1.1.3" -m "v1.1.3"
git push upstream --follow-tags
- Lift the pull request merge freeze
- Create release on GitHub
Close out the current milestone after moving all issues to the next one that were still unresolved in it
yarn run configure && yarn run build && yarn lerna publish from-git --loglevel=debug --summary-file
yarn lerna publish from-git --loglevel=debug --force-publish --ignore-scripts --ignore-prepublish --summary-file