From 29b64bdb17d5386b834c6938934d770ff62e4746 Mon Sep 17 00:00:00 2001
From: Dan Finlay <dan@danfinlay.com>
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 c8fb53cd8..25aff9134 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 77dcc1412..53dbcf88e 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 <dan@danfinlay.com>
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 45662900d..132c28d9b 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 000000000..e2c4e2f3d
--- /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.
+