From 29b64bdb17d5386b834c6938934d770ff62e4746 Mon Sep 17 00:00:00 2001 From: Dan Finlay Date: Tue, 19 Feb 2019 12:22:01 -0800 Subject: [PATCH 1/2] Version 6.1.0 RC1 --- CHANGELOG.md | 8 ++++++++ app/manifest.json | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index c8fb53cd8120..25aff9134caf 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,14 @@ ## Current Develop Branch +## 6.1.0 Tue Feb 19 2019 + +- [#6182](https://github.com/MetaMask/metamask-extension/pull/6182): Change "Token Address" to "Token Contract Address" +- [#6177](https://github.com/MetaMask/metamask-extension/pull/6177): Fixes #6176 +- [#6146](https://github.com/MetaMask/metamask-extension/pull/6146): * Add Copy Tx ID button to transaction-list-item-details +- [#6133](https://github.com/MetaMask/metamask-extension/pull/6133): Checksum address before slicing it for the confirm screen +- [#6147](https://github.com/MetaMask/metamask-extension/pull/6147): Add button to force edit token symbol when adding custom token +- [#6124](https://github.com/MetaMask/metamask-extension/pull/6124): recent-blocks - dont listen for block when on infura providers -[#5973] (https://github.com/MetaMask/metamask-extension/pull/5973): Fix incorrectly showing checksums on non-ETH blockchains (issue 5838) ## 6.0.1 Tue Feb 12 2019 diff --git a/app/manifest.json b/app/manifest.json index 77dcc1412a0d..53dbcf88ef07 100644 --- a/app/manifest.json +++ b/app/manifest.json @@ -1,7 +1,7 @@ { "name": "__MSG_appName__", "short_name": "__MSG_appName__", - "version": "6.0.1", + "version": "6.1.0", "manifest_version": 2, "author": "https://metamask.io", "description": "__MSG_appDescription__", From 160f1961654632654072759f0aa116b43a97f35b Mon Sep 17 00:00:00 2001 From: Dan Finlay Date: Tue, 19 Feb 2019 12:33:12 -0800 Subject: [PATCH 2/2] Add sensitive publishing protocol --- docs/publishing.md | 4 ++++ docs/sensitive-release.md | 43 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 47 insertions(+) create mode 100644 docs/sensitive-release.md diff --git a/docs/publishing.md b/docs/publishing.md index 45662900df1d..132c28d9b61e 100644 --- a/docs/publishing.md +++ b/docs/publishing.md @@ -17,6 +17,10 @@ Version can be automatically incremented [using our bump script](./bumping-versi npm run version:bump $BUMP_TYPE` where `$BUMP_TYPE` is one of `major`, `minor`, or `patch`. +## Preparing for Sensitive Changes + +In the case that a new release has sensitive changes that cannot be fully verified prior to publication, please follow the [sensitive release protocol](./sensitive-release.md). + ## Building While we develop on the main `develop` branch, our production version is maintained on the `master` branch. diff --git a/docs/sensitive-release.md b/docs/sensitive-release.md new file mode 100644 index 000000000000..e2c4e2f3d611 --- /dev/null +++ b/docs/sensitive-release.md @@ -0,0 +1,43 @@ +# Sensitive Release Protocol + +In the case that a new change is so dramatic that it is hard to anticipate all of the potential side-effects, here is a protocol for rolling out these sensitive changes in a way that: + +- Minimizes adverse impact on end users. +- Maximizes our responsiveness to these changes. + +## Protocol Steps + +1. Prepare a normal release. +2. Prepare a rollback release. +3. Roll the normal release out. +4. In case of emergency, roll back. + +### Normal Release + +Simply follow the steps in [the publishing guide](./publishing.md). + +### Prepare Rollback Release + +1. Check out the tagged commit for the release before this new release. +2. Increment the version over the new release by one patch. +3. Merge the changelog of the new release into this branch, and make its own changelog refer to rolling back those changes. +4. Push to the main repository and pull request against `master` prominently noting this is a `DO NOT MERGE` rollback pull request. + +### Roll the normal release out + +Ensure the rollback release has been built, and downloaded locally, fully ready to deploy with immediacy. + +For a sensitive release, initially roll out to only 1% of Chrome users (since Chrome allows incremental rollout). + +Monitor Sentry for any recognizable error logs. + +Gradually increase the rollout percentage. + +### In case of Emergency + +If a problem is detected, publish the roll-back release to 100% of users, identify the issue, fix it, and repeat this process with a new release. + +## Summary + +This protocol is a worst-case scenario, just a way to be incredibly careful about our most sensitive possible changes. +