Remove ethpm.json and update releasing docs (#2205)

* remove ethpm.json

* update releasing document

* fix release documentation to be more realistic

RELEASING.md

 # 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.
+> Visit the documentation for [details about release schedule].
 
-We release a new version of OpenZeppelin monthly. Release cycles are tracked in the [issue milestones](https://github.com/OpenZeppelin/openzeppelin-contracts/milestones).
+Start on an up-to-date `master` branch.
 
-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.
+Create the release branch with `npm run release start minor`.
 
-Before starting make sure to verify the following items.
-* Your local `master` branch is in sync with your `upstream` remote (it may have another name depending on your setup).
-* Your repo is clean, particularly with no untracked files in the contracts and tests directories. Verify with `git clean -n`.
+Publish a release candidate with `npm run release rc`.
 
+Publish the final release with `npm run release final`.
 
-## Creating the release branch
+Follow the general [OpenZeppelin release checklist].
 
-We'll refer to a release `vX.Y.Z`.
+[details about release schedule]: https://docs.openzeppelin.com/contracts/releases-stability
+[OpenZeppelin release checklist]: https://github.com/OpenZeppelin/code-style/blob/master/RELEASE_CHECKLIST.md
 
-```
-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-contracts/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 under the `next` tag. You should see the contracts compile automatically.
-
-```
-npm publish --tag next
-```
-
-Publish the release notes on GitHub and the forum, and ask our community manager to announce the release candidate on at least Twitter.
-
-## Creating the final release
-
-Make sure to have the latest changes from `upstream` in your local release branch.
-
-```
-git checkout release-vX.Y.Z
-git pull upstream
-```
-
-Before starting the release process, make one final commit to CHANGELOG.md, including the date of the release.
-
-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 release-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. You should see the contracts compile automatically.
-
-```
-npm publish
-```
-
-Publish the release notes on GitHub and ask our community manager to announce the release!
-
-Delete the `next` tag in the npm package as there is no longer a release candidate.
-
-```
-npm dist-tag rm --otp $2FA_CODE @openzeppelin/contracts next
-```
 
 ## Merging the release branch
 

docs/modules/ROOT/pages/releases-stability.adoc

@@ -12,7 +12,7 @@ OpenZeppelin Contracts follows a <<versioning-scheme, semantic versioning scheme
 [[minor-releases]]
 === Minor Releases
 
-OpenZeppelin Contracts has a *5 week release cycle*. This means that every five weeks a new release is published.
+OpenZeppelin Contracts aims for a new minor release every 1 or 2 months.
 
 At the beginning of the release cycle we decide which issues we want to prioritize, and assign them to https://github.com/OpenZeppelin/openzeppelin-contracts/milestones[a milestone on GitHub]. During the next five weeks, they are worked on and fixed.
 
@@ -21,7 +21,7 @@ Once the milestone is complete, we publish a feature-frozen release candidate. T
 [[major-releases]]
 === Major Releases
 
-Every several months a new major release may come out. These are not scheduled, but will be based on the need to release breaking changes such as a redesign of a core feature of the library (e.g. https://github.com/OpenZeppelin/openzeppelin-contracts/issues/1146[roles] in 2.0). Since we value stability, we aim for these to happen infrequently (expect no less than six months between majors). However, we may be forced to release one when there are big changes to the Solidity language.
+After several months or a year a new major release may come out. These are not scheduled, but will be based on the need to release breaking changes such as a redesign of a core feature of the library (e.g. https://github.com/OpenZeppelin/openzeppelin-contracts/pulls/2112[access control] in 3.0). Since we value stability, we aim for these to happen infrequently (expect no less than six months between majors). However, we may be forced to release one when there are big changes to the Solidity language.
 
 [[api-stability]]
 == API Stability

ethpm.json

-{
-  "package_name": "zeppelin",
-  "version": "2.5.0",
-  "description": "Secure Smart Contract library for Solidity",
-  "authors": [
-    "OpenZeppelin Community <maintainers@openzeppelin.org>"
-  ],
-  "keywords": [
-    "solidity",
-    "ethereum",
-    "smart",
-    "contracts",
-    "security",
-    "zeppelin"
-  ],
-  "license": "MIT"
-}

scripts/release/synchronize-versions.js

 #!/usr/bin/env node
 
-// Synchronizes the versions in ethpm.json and contracts/package.json with the
-// one in package.json.
+// Synchronizes the version in contracts/package.json with the one in package.json.
 // This is run automatically when npm version is run.
 
 const fs = require('fs');
 const cp = require('child_process');
 
 setVersion('contracts/package.json');
-setVersion('ethpm.json');
 
 function setVersion (file) {
   const json = JSON.parse(fs.readFileSync(file));