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

* 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

RELEASING.md

@@ -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.