Skip to content
This repository has been archived by the owner on Dec 27, 2022. It is now read-only.

Home

Jump to bottom
Paul Frazee edited this page Oct 18, 2016 · 4 revisions

Beaker uses an Electron fork to

  1. use custom changes prior to their getting merged into Electron main, and
  2. use custom changes that will never get merged into Electron main.

We try to avoid the latter as much as possible.

The fork should track closely with GitHub's main, so that new updates can be transferred in both directions. To ensure this, follow the procedure outlined below.

Procedure

Master Branch

The master branch should stay up to date with electron/electron's master. There should be no custom code in this branch.

Feature Branches

Every change to electron/electron made by beakerbrowser/electron should be implemented and maintained in a feature branch. The branch should be descriptively named; eg, for an API to put red borders on windows, the branch would be named red-borders.

Every feature branch should have a corresponding Wiki page, with the same name as the branch. The Wiki page will explain the feature, and give information about its merge status into electron/electron. If the feature is never meant to be merged into electron/electron, the Wiki page should say so.

Feature branches should not be deleted until they have been merged into electron/electron.

Version Branches

For every new major/minor/patch release of electron/electron that beaker uses, there should be a beakerbrowser/electron branch with a matching name. For instance, for electron/electron v1.4.3, there should be a beakerbrowser/electron branch named 1.4.3. These are "version" branches.

The version branches will be used by Beaker. They should be created with the following procedure:

  1. Branch from electron/electron's master branch at the corresponding version tag
  2. Merge any outstanding feature branches in beakerbrowser/electron. If the feature branch had to be updated during the merge, those updates should be added to the feature branch. This may require cherry-picking.

Deployment

To deploy a new version of beakerbrowser/electron, follow these steps:

  1. Build the Version branch for the target platforms.
  2. Zip the compiled builds and upload them to beakerbrowser/electron releases on GitHub. The filenames should mimic the structure used in electron/electron releases.
  3. Create SHASUMS256.txt and upload it to beakerbrowser/electron.
  4. Update the version in beakerbrowser/electron-prebuilt.
  5. Build Beaker for the target platforms.

Roadmap to removing Electron

Beaker uses electron for two reasons:

  1. To build the Browser UI using HTML/CSS/JS
  2. To run the Dat protocol, which requires the node runtime

In the future, the Dat protocol will be implemented in Rust. When this is complete, we will diverge from Electron entirely, and strip out the node runtime.

Whenever possible, Chromium's existing features should be used. This will likely depend on exposing the features as JS APIs. For instance, Chromium possesses a History DB, which Beaker does not currently use (it has a custom SQLite history DB). This doesn't make sense; we should use Chromium's History DB, which is well-developed.

Clone this wiki locally