Skip to content

publishing.md

Latest commit

 

History

History
53 lines (32 loc) · 3.12 KB

publishing.md

File metadata and controls

53 lines (32 loc) · 3.12 KB

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.

mm-dev-process

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 by creating a branch with the name release/X.Y.Z, where X, Y, and Z are numbers. Branches should be created off of the main branch. Branches can be created on GitHub.

Once a version branch has been created, a build on CI will create a Pull Request for the release with the app manifest and changelog versions bumped.

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.

Building

While we develop on the main branch, our production builds are created from the release branch HEAD using the publish-release-from-release-head.yml workflow. This workflow builds, tags, and publishes from the release branch before it is merged to stable.

Publishing

  1. Publish to chrome store.
  2. Visit the chrome developer dashboard.
  3. Publish to firefox addon marketplace.
  4. Publish to Opera store.
  5. Post on Github releases page.
  6. Run the yarn announce script, and post that announcement in our public places.

Hotfix Differences

Our main 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 stable branch.

Publishing is done from the hotfix branch HEAD using the publish-release-from-release-head.yml workflow. After publishing, the hotfix branch is merged to stable, and stable-sync PRs propagate changes back to main.