mirror of
https://github.com/kremalicious/metamask-extension.git
synced 2024-12-23 09:52:26 +01:00
commit
d4ea1a6645
@ -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
|
||||
|
@ -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__",
|
||||
|
@ -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
43
docs/sensitive-release.md
Normal 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.
|
||||
|
Loading…
Reference in New Issue
Block a user