Beta distribution

[Gudahtt]

This is a tracking issue for all of the tasks relating to creating a beta distribution of the extension. Some of these points will be adjusted or expanded as we further refine our plans.

• [x] Design beta release
  • Design changes include: new logo, new warnings during onboarding, possibly warnings elsewhere as well
• [x] Add build flag for "beta" build which triggers different icon/branding, and warning messages
  • Any static MetaMask logo images (e.g. on the Home page and logic page, during onboarding, the favicon) should be updated to use a beta MetaMask logo
  • We should display a warning upon install to ensure users understand the risks
  • We should consider displaying warnings elsewhere in the application as well (to be determined)
  • This flag should require that a beta version number is specified
  • This flag should ensure the Sentry environment used is "beta"
• [ ] Trigger a "beta" build when a non-hotfix release candidate is ready to publish
  • Our release automation scripts should recognize this scenario and trigger a "beta" build rather than a production build, using the beta release version (which is of the format X.Y.Z-beta.N, where X.Y.Z will be the final production version after it passes beta, and N is the beta build number, starting at 0)
• [ ] Setup a process for creating a new release candidate to address problems found during the beta
  • This should increment the beta build number, and produce a new beta build when approved
• [ ] Setup a process for building a production release, once the beta period has ended and we have a build that we are confident in
  • This should be a process similar to the one we use for creating release candidates, so that we can have a final QA pass.
• [x] Write extension store description
• [x] Add page to website for beta
  • This should be our authoritative link to the beta distributions for each browser
  • This should explain the intended usage, including any relevant warnings and disclaimers
• [x] Create marketing campaign to explain and promote the beta distribution
• [x] Ensure the support form has an option for the extension beta

Non-blocking goals:

• [ ] Beta-specific migrations
  • This might be useful if we want to make state changes during the beta that don't affect production users
  • This could be used to wipe state completely if we make a horrendous mistake, or to undo or wipe out specific things.
• [ ] Consider including Flask description/preview in website update and marketing campaigns
  • Since we're hoping to introduce Flask in the next few months, explaining it now might offset confusion from introducing a third distribution in such a short time frame.

[hilvmason]

@brad-decker @danjm -- just flagging that this original beta issue has been pulled into the MV3 board to execute MV3 beta. I see the contributor experience label has also been added, so ensuring there is no duplication of work here! Perhaps we need to break this up to make ready for MV3 beta (specifically), and what work the contributor experience team may take on in the future?

[hilvmason]

@danjm will revise this issue to cover MV3 Beta only, splitting other issues for future iteration as needed

[hilvmason]

hey @danjm -- checking on this issue, will this be revised or another issue opened to address MV3 Beta, specifically?

[danjm]

Hey team! Please add your planning poker estimate with Zenhub @brad-decker @DDDDDanica @pedronfigueiredo @PeterYinusa