metamask-extension/docs/publishing.md

# Publishing Guide

When publishing a new version of MetaMask, we follow this procedure:

## Overview

The below diagram outlines our process for design, development, and release. Building MetaMask is a community affair, and many steps of the process invite participation from external contributors as indicated. All QA, code review, and release of new versions is done by members of the core MetaMask team.

<img width="664" alt="mm-dev-process" src="https://user-images.githubusercontent.com/1016190/56308059-36906000-60fb-11e9-8e61-6655bca0c54f.png">


## Preparation

We try to ensure certain criteria are met before deploying:

- Deploy early in the week, to give time for emergency responses to unforeseen bugs.
- Deploy early in the day, for the same reason.
- Make sure at least one member of the support team is "on duty" to watch for new user issues coming through the support system.
- Roll out incrementally when possible, to a small number of users first, and gradually to more users.

## Incrementing Version & Changelog

Version can be automatically incremented [using our bump script](./bumping-version.md).

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.

With each pull request, the @MetaMaskBot will comment with a build of that new pull request, so after bumping the version on `develop`, open a pull request against `master`, and once the pull request is reviewed and merged, you can download those builds for publication.

## Publishing

1. Publish to chrome store.
2. Visit [the chrome developer dashboard](https://chrome.google.com/webstore/developer/dashboard?authuser=2).
3. Publish to [firefox addon marketplace](http://addons.mozilla.org/en-us/firefox/addon/ether-metamask).
4. Publish to [Opera store](https://addons.opera.com/en/extensions/details/metamask/).
5. Post on [Github releases](https://github.com/MetaMask/metamask-extension/releases) page.
6. Run the `npm run announce` script, and post that announcement in our public places.

## Hotfix Differences

Our `develop` branch is usually not yet fully tested for quality assurance, and so should be treated as if it is in an unstable state.

For this reason, when an urgent change is needed in production, its pull request should:

- Describe it as a hotfix.
- Use a hotfix tag.
- Should be proposed against the `master` branch.

The version and changelog bump should then be made off the `master` branch, and then merged to `develop` to bring the two branches back into sync. Further time can be saved by incorporating the version/changelog bump into the PR against `master`, since we rely on @MetaMaskBot to run tests before merging.
Add publishing guide 2017-06-05 22:46:18 +02:00			`# Publishing Guide`

			`When publishing a new version of MetaMask, we follow this procedure:`

update publishing.md with dev diagram 2019-04-17 19:30:17 +02:00			`## Overview`

			`The below diagram outlines our process for design, development, and release. Building MetaMask is a community affair, and many steps of the process invite participation from external contributors as indicated. All QA, code review, and release of new versions is done by members of the core MetaMask team.`

			`<img width="664" alt="mm-dev-process" src="https://user-images.githubusercontent.com/1016190/56308059-36906000-60fb-11e9-8e61-6655bca0c54f.png">`


Update publishing guide 2018-05-23 23:48:05 +02:00			`## Preparation`

			`We try to ensure certain criteria are met before deploying:`

			`- Deploy early in the week, to give time for emergency responses to unforeseen bugs.`
			`- Deploy early in the day, for the same reason.`
			`- Make sure at least one member of the support team is "on duty" to watch for new user issues coming through the support system.`
			`- Roll out incrementally when possible, to a small number of users first, and gradually to more users.`

Break docs up into individual files 2017-06-05 22:55:48 +02:00			`## Incrementing Version & Changelog`

Add version bumping script One step towards automating our deploy process is automating our version bumping scheme. This PR does that. 2018-03-02 22:55:56 +01:00			`Version can be automatically incremented [using our bump script](./bumping-version.md).`
Break docs up into individual files 2017-06-05 22:55:48 +02:00
doc - publishing - typo fix (#6399) 2019-04-04 20:49:37 +02:00			npm run version:bump `$BUMP_TYPE` where `$BUMP_TYPE` is one of `major`, `minor`, or `patch`.
Break docs up into individual files 2017-06-05 22:55:48 +02:00
Add sensitive publishing protocol 2019-02-19 21:33:12 +01:00			`## 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).`

Update publishing guide 2018-05-23 23:48:05 +02:00			`## Building`

			While we develop on the main `develop` branch, our production version is maintained on the `master` branch.

			With each pull request, the @MetaMaskBot will comment with a build of that new pull request, so after bumping the version on `develop`, open a pull request against `master`, and once the pull request is reviewed and merged, you can download those builds for publication.

Break docs up into individual files 2017-06-05 22:55:48 +02:00			`## Publishing`

Update publishing guide 2018-05-23 23:48:05 +02:00			`1. Publish to chrome store.`
Update publishing.md 2018-05-23 23:58:09 +02:00			`2. Visit [the chrome developer dashboard](https://chrome.google.com/webstore/developer/dashboard?authuser=2).`
			`3. Publish to [firefox addon marketplace](http://addons.mozilla.org/en-us/firefox/addon/ether-metamask).`
			`4. Publish to [Opera store](https://addons.opera.com/en/extensions/details/metamask/).`
			`5. Post on [Github releases](https://github.com/MetaMask/metamask-extension/releases) page.`
			6. Run the `npm run announce` script, and post that announcement in our public places.
Document hotfix protocol 2019-05-09 21:35:24 +02:00
			`## Hotfix Differences`

			Our `develop` branch is usually not yet fully tested for quality assurance, and so should be treated as if it is in an unstable state.

			`For this reason, when an urgent change is needed in production, its pull request should:`

			`- Describe it as a hotfix.`
			`- Use a hotfix tag.`
			- Should be proposed against the `master` branch.

			The version and changelog bump should then be made off the `master` branch, and then merged to `develop` to bring the two branches back into sync. Further time can be saved by incorporating the version/changelog bump into the PR against `master`, since we rely on @MetaMaskBot to run tests before merging.