Skip to content

Latest commit

 

History

History
80 lines (53 loc) · 3 KB

RELEASING.md

File metadata and controls

80 lines (53 loc) · 3 KB

Releasing

This document describes our release process, and contains the steps to be followed by an OpenZeppelin maintainer at the several stages of a release.

We release a new version of OpenZeppelin monthly. Release cycles are tracked in the issue milestones.

Each release has at least one release candidate published first, intended for community review and any critical fixes that may come out of it. At the moment we leave 1 week between the first release candidate and the final release.

Before starting make sure to verify the following items.

  • Your local master branch is in sync with your upstream remote.
  • Your repo is clean, particularly with no untracked files in the contracts and tests directories. Verify with git clean -n.

Creating the release branch

We'll refer to a release vX.Y.Z.

git checkout master
git checkout -b release-vX.Y.Z

Creating a release candidate

Once in the release branch, change the version string in package.json, package-lock.json and ethpm.json to X.Y.Z-rc.R. (This will be X.Y.Z-rc.1 for the first release candidate.) Commit these changes and tag the commit as vX.Y.Z-rc.R.

git add package.json package-lock.json ethpm.json
git commit -m "Release candidate vX.Y.Z-rc.R"
git tag -a vX.Y.Z-rc.R
git push upstream release-vX.Y.Z
git push upstream vX.Y.Z-rc.R

Draft the release notes in our GitHub releases. Make sure to mark it as a pre-release! Try to be consistent with our previous release notes in the title and format of the text. Release candidates don't need a detailed changelog, but make sure to include a link to GitHub's compare page.

Once the CI run for the new tag is green, publish on npm.

npm publish

Publish the release notes on GitHub and ask our community manager to announce the release candidate on at least Slack and Twitter.

Creating the final release

git checkout release-vX.Y.Z

Change the version string in package.json, package-lock.json and ethpm.json removing the "-rc.R" suffix. Commit these changes and tag the commit as vX.Y.Z.

git add package.json package-lock.json ethpm.json
git commit -m "Release vX.Y.Z"
git tag -a vX.Y.Z
git push upstream vX.Y.Z

Draft the release notes in GitHub releases. Try to be consistent with our previous release notes in the title and format of the text. Make sure to include a detailed changelog.

Once the CI run for the new tag is green, publish on npm.

npm publish

Publish the release notes on GitHub and ask our community manager to announce the release!

Merging the release branch

After the final release, the release branch should be merged back into master. This merge must not be squashed, because it would lose the tagged release commit, so it should be merged locally and pushed.

git checkout master
git merge --no-ff release-vX.Y.Z
git push upstream master

The release branch can then be deleted on GitHub.