From 528c23d6799e51b02f1b58514fde93a6de128f7a Mon Sep 17 00:00:00 2001 From: Francisco Giordano Date: Mon, 20 Apr 2020 20:10:30 -0300 Subject: [PATCH] Remove ethpm.json and update releasing docs (#2205) * remove ethpm.json * update releasing document * fix release documentation to be more realistic --- RELEASING.md | 79 ++----------------- .../ROOT/pages/releases-stability.adoc | 4 +- ethpm.json | 17 ---- scripts/release/synchronize-versions.js | 4 +- 4 files changed, 11 insertions(+), 93 deletions(-) delete mode 100644 ethpm.json diff --git a/RELEASING.md b/RELEASING.md index 8934ff70c..5840c9c9f 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -1,83 +1,20 @@ # 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 diff --git a/docs/modules/ROOT/pages/releases-stability.adoc b/docs/modules/ROOT/pages/releases-stability.adoc index 2efee0306..94dbb3972 100644 --- a/docs/modules/ROOT/pages/releases-stability.adoc +++ b/docs/modules/ROOT/pages/releases-stability.adoc @@ -12,7 +12,7 @@ OpenZeppelin Contracts follows a <" - ], - "keywords": [ - "solidity", - "ethereum", - "smart", - "contracts", - "security", - "zeppelin" - ], - "license": "MIT" -} diff --git a/scripts/release/synchronize-versions.js b/scripts/release/synchronize-versions.js index cadb6be43..15915a1c8 100755 --- a/scripts/release/synchronize-versions.js +++ b/scripts/release/synchronize-versions.js @@ -1,14 +1,12 @@ #!/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));