1
0
mirror of https://github.com/kremalicious/metamask-extension.git synced 2024-12-23 09:52:26 +01:00

Merge pull request #6187 from MetaMask/Version-6.1.0

Version 6.1.0
This commit is contained in:
Thomas Huang 2019-02-19 15:44:09 -08:00 committed by GitHub
commit d4ea1a6645
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 56 additions and 1 deletions

View File

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

View File

@ -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__",

View File

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

43
docs/sensitive-release.md Normal file
View File

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