-
Notifications
You must be signed in to change notification settings - Fork 136
Brave UI | Core
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.
- Merge
brave-ui
PR to master on approval - Cherry-pick inside brave-ui repo to brave-core-0.VV.x branches
- Create PR within
brave-core
for each release branch, based on that release branch, to update package.json.
- Core Master to brave-ui master: needs approval
- Core Dev branch to Brave UI Dev branch: can merge without approval
- Core Beta branch to Brave UI Beta branch: needs approval
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.
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.
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
.
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.