Skip to content
This repository has been archived by the owner on May 13, 2024. It is now read-only.

Brave UI | Core

Ross Moody edited this page Mar 2, 2019 · 1 revision

Version branches in brave-ui will now match version branches in brave-core which is our main consuming app.

For more information: the Brave Release Schedule.

We will still publish to npm for foundational brave-ui changes so that other apps receive updates.

Process

Summary

  1. Merge brave-ui PR to master on approval
  2. Cherry-pick inside brave-ui repo to brave-core-0.VV.x branches
  3. Create PR within brave-core for each release branch, based on that release branch, to update package.json.

Approvals

  1. Core Master to brave-ui master: needs approval
  2. Core Dev branch to Brave UI Dev branch: can merge without approval
  3. Core Beta branch to Brave UI Beta branch: needs approval

Feature-specific Components in Brave Core

In Brave UI we have three branches consisting of master and the two equivalents of beta and dev in Brave Core. For naming convention we follow brave-core-VERSION_TAG so if something needs to land in Brave Core branch 0.58.x, the Brave UI branch will be named brave-core-0.58.x.

Author should target the master branch and once it has landed either the author or the reviewer should ask for uplift request (same mechanism as brave-core). It should then be cherry-picked using the commit sha i.e. git cherry-pick -m 1 SHA.

Once changes are merged and in the appropriate branch, the author should apply changes in brave-core referencing the sha in package.json.

Shared Components

We decided to freeze npm releases until another set of changes come from design so any changes in shared components would follow the above method. We will be discussing npm releases in a later meeting. Latest public version is v0.36.0.

Example Scenario

A patch for Brave Rewards is needed for 0.58.x.

The author would make the changes in brave-ui and follow the usual PR process. Once approved and merged, either author or reviewer would request an uplift to the brave-core-0.58.x branch. Once approved and cherry-picked to that branch, the author would reference the new commit sha in the package.json PR against brave-core.

Once that is merged, [email protected] would then have the same features available in the respective branch of brave-ui.

Cascading Changes

Following the same procedure of brave-core, if a feature targets the release channel for example, all the next branches (beta, dev and nightly) would get the same changes. So cherry-picking would be made against all following branches after your target. The same goes for changes in other branches such as dev. In this case only dev and nightly would receive the commit sha and all branches landing before them would be skipped.