NoBey/openzeppelin-contracts
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add an initial document for our release process (#1140)

Browse Source 
* Add an initial document for our release process

* add more detail and explanation to releasing guide

* fix details of the RELEASING.md document

* Update RELEASING.md

* Update RELEASING.md

* Update RELEASING.md

* Update RELEASING.md
This commit is contained in:
Leo Arias
2018-08-01 16:16:56 -06:00
committed by Francisco Giordano
parent 89ccb03e6e
commit 1dcefa6bd3
1 changed files with 80 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

80
RELEASING.md Normal file
View File

@ -0,0 +1,80 @@
# 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](https://github.com/OpenZeppelin/openzeppelin-solidity/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](https://github.com/OpenZeppelin/openzeppelin-solidity/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.