new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Electron · Tutorial · all subjects

versioning

10 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Electron follows SemVer from version 2.0.0 onwards

As of version 2.0.0, Electron follows the Semantic Versioning 2.0.0 specification for versioning.

SemVer mapping: Major, Minor, and Patch version increments

Major Version Increments: Electron breaking API changes, Node.js major version updates, Chromium version updates. Minor Version Increments: Electron non-breaking API changes, Node.js minor version updates. Patch Version Increments: Electron bug fixes, Node.js patch version updates, fix-related Chromium patches. Most Chromium updates are considered breaking changes, but fixes that can be backported will likely be cherry-picked as patches.

Stabilization branches run parallel to main for security and stability

Stabilization branches run parallel to the main branch and only accept cherry-picked commits related to security or stability. These branches are never merged back to main. Since Electron 8, stabilization branches are always major version lines, named using the template $MAJOR-x-y, for example 8-x-y. Multiple stabilization branches can exist simultaneously, one for each supported version.

Electron release cycle is 8 weeks

Electron follows an 8-week regular release cycle where key milestones correspond to matching dates in the Chromium release cycle. The release cycle includes alpha phase (4 weeks), beta phase (4 weeks), and stable release, with versions supported for approximately 12 weeks from stable release.

Feature flags must be runtime or build-time configurable

Feature flags, also called soft branches in Electron context, must be enabled or disabled either at runtime or build-time. Electron does not support request-scoped feature flags. Feature flags must completely segment new and old code paths, and refactoring old code to support a new feature violates the feature-flag contract. Feature flags are eventually removed after the feature is released.

Conventional Commits specification for pull requests

All pull requests must adhere to the Conventional Commits specification. Commits that would result in a SemVer major bump must start their body with 'BREAKING CHANGE:'. Commits for a minor bump must start with 'feat:'. Commits for a patch bump must start with 'fix:'. The electron/electron repository enforces squash merging, so only the pull request title prefix needs the correct format.

Main branch versioning and nightly releases

The main branch always corresponds to the major version above the current pre-release line. Unstable nightly releases of main are released under the 'electron-nightly' package on npm. Release branches are never merged back to main. All package.json values in main are fixed at '0.0.0-development'.

Historical Electron 1.x versioning problems

Electron versions prior to 2.0 did not conform to SemVer. Major versions corresponded to end-user API changes, minor versions corresponded to Chromium major releases, and patch versions corresponded to new features and bug fixes. This created problems where an app could not adopt a bug fix without also absorbing new features or backporting fixes to maintain a separate release line. This strategy was problematic for client-facing applications with lengthy QA testing cycles.

Backport request process for supported release lines

All supported release lines accept external pull requests to backport fixes previously merged to main, though this may be on a case-by-case basis for some older supported lines. Contested decisions around release line backports are resolved by the Releases Working Group as an agenda item at their weekly meeting the week the backport PR is raised.

Installing prerelease versions of Electron

Electron distributes experimental releases via npm. Nightly builds containing the latest changes from the main branch can be installed with `npm install electron-nightly --save-dev`. Alpha and beta builds for the next major version can be installed with `npm install electron@alpha --save-dev` or `npm install electron@beta --save-dev`.

Give your agent this brain