m/metamask-extension
1
0
Fork 0
mirror of https://github.com/kremalicious/metamask-extension.git synced 2024-11-30 08:09:15 +01:00
Code
281aea7d3f
metamask-extension/docs/publishing.md

58 lines
3.2 KiB
Markdown
Raw Normal View History

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
Update publishing doc to reflect automation (#6899)
2019-07-30 15:23:04 +02:00
Version can be automatically incremented by creating a branch with the name `Version-vX.Y.Z`, where `X`, `Y`, and `Z` are numbers. Branches should be created off of the main branch. [Branches can be created on GitHub.](https://help.github.com/en/articles/creating-and-deleting-branches-within-your-repository)
Break docs up into individual files
2017-06-05 22:55:48 +02:00
Update publishing doc to reflect automation (#6899)
2019-07-30 15:23:04 +02:00
Once a version branch has been created, a build on CircleCI will create a Pull Request for the release with the app manifest and changelog versions bumped.
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.
Switch from `npm` to `yarn` (#6843) As a solution to the constant lockfile churn issues we've had with `npm`, the project now uses `yarn` to manage dependencies. The `package-lock.json` file has been replaced with `yarn.lock`, which was created using `yarn import`. It should approximate the contents of `package-lock.json` fairly well, though there may be some changes due to deduplication. The codeowners file has been updated to reference this new lockfile. All documentation and npm scripts have been updated to reference `yarn` rather than `npm`. Note that running scripts using `npm run` still works fine, but it seemed better to switch those to `yarn` as well to avoid confusion. The `npm-audit` Bash script has been replaced with `yarn-audit`. The output of `yarn audit` is a bit different than `npm audit` in that it returns a bitmask to describe which severity issues were found. This made it simpler to check the results directly from the Bash script, so the associated `npm-audit-check.js` script was no longer required. The output should be exactly the same, and the information is still sourced from the same place (the npm registry). The new `yarn-audit` script does have an external dependency: `jq`. However, `jq` is already assumed to be present by another CI script, and is present on all CI images we use. `jq` was not added to `package.json` as a dependency because there is no official package on the npm registry, just wrapper scripts. We don't need it anywhere exept on CI anyway. The section in `CONTRIBUTING` about how to develop inside the `node_modules` folder was removed, as the advice was a bit dated, and wasn't specific to this project anyway.
2019-07-30 20:36:23 +02:00
6. Run the `yarn 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.
Copy Permalink