A detailed look at our versioning policy and implementation.
As of version 2.0.0, Electron follows semver. The following command will install the most recent stable build of Electron:
npm install --save-dev electron
To update an existing project to use the latest stable version:
npm install --save-dev electron@latest
Electron versions < 2.0 did not conform to the semver spec: 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. While convenient for developers merging features, it creates problems for developers of client-facing applications. The QA testing cycles of major apps like Slack, Stride, Teams, Skype, VS Code, Atom, and Desktop can be lengthy and stability is a highly desired outcome. There is a high risk in adopting new features while trying to absorb bug fixes.
Here is an example of the 1.x strategy:
An app developed with
1.8.1 cannot take the
1.8.3 bug fix without either absorbing the
1.8.2 feature, or by backporting the fix and maintaining a new release line.
There are several major changes from our 1.x strategy outlined below. Each change is intended to satisfy the needs and priorities of developers/maintainers and app developers.
masterbranch is versionless; only stabilization branches contain version information
We will cover in detail how git branching works, how npm tagging works, what developers should expect to see, and how one can backport changes.
From 2.0 onward, Electron will follow semver.
Below is a table explicitly mapping types of changes to their corresponding category of semver (e.g. Major, Minor, Patch).
|Major Version Increments||Minor Version Increments||Patch Version Increments|
|Electron breaking API changes||Electron non-breaking API changes||Electron bug fixes|
|Node.js major version updates||Node.js minor version updates||Node.js patch version updates|
|Chromium version updates||fix-related chromium patches|
Note that most Chromium updates will be considered breaking. Fixes that can be backported will likely be cherry-picked as patches.
Stabilization branches are branches that run parallel to master, taking in only cherry-picked commits that are related to security or stability. These branches are never merged back to master.
Stabilization branches are always either major or minor version lines, and named against the following template
We allow for multiple stabilization branches to exist simultaneously, and intend to support at least two in parallel at all times, backporting security fixes as necessary.
Older lines will not be supported by GitHub, but other groups can take ownership and backport stability and security fixes on their own. We discourage this, but recognize that it makes life easier for many app developers.
Developers want to know which releases are safe to use. Even seemingly innocent features can introduce regressions in complex applications. At the same time, locking to a fixed version is dangerous because you’re ignoring security patches and bug fixes that may have come out since your version. Our goal is to allow the following standard semver ranges in
~2.0.0to admit only stability or security related fixes to your
^2.0.0to admit non-breaking reasonably stable feature work as well as security and bug fixes.
What’s important about the second point is that apps using
^ should still be able to expect a reasonable level of stability. To accomplish this, semver allows for a pre-release identifier to indicate a particular version is not yet safe or stable.
Whatever you choose, you will periodically have to bump the version in your
package.json as breaking changes are a fact of Chromium life.
The process is as follows:
All new major and minor releases lines begin with a beta series indicated by semver prerelease tags of
2.0.0-beta.1. After the first beta, subsequent beta releases must meet all of the following conditions:
2.0.0. After the first stable, all changes must be backwards-compatible bug or security fixes.
Specifically, the above means:
For each major and minor bump, you should expect to see something like the following:
2.0.0-beta.1 2.0.0-beta.2 2.0.0-beta.3 2.0.0 2.0.1 2.0.2
An example lifecycle in pictures:
2-0-xline and release
A few examples of how various semver ranges will pick up new releases:
Our strategy has a few tradeoffs, which for now we feel are appropriate. Most importantly that new features in master may take a while before reaching a stable release line. If you want to try a new feature immediately, you will have to build Electron yourself.
As a future consideration, we may introduce one or both of the following:
Feature flags are a common practice in Chromium, and are well-established in the web-development ecosystem. In the context of Electron, a feature flag or soft branch must have the following properties:
We seek to increase clarity at all levels of the update and releases process. Starting with
2.0.0 we will require pull requests adhere to the Conventional Commits spec, which can be summarized as follows:
Commits that would result in a semver major bump must start their body with
Commits that would result in a semver minor bump must start with
Commits that would result in a semver patch bump must start with
We allow squashing of commits, provided that the squashed message adheres the the above message format.
It is acceptable for some commits in a pull request to not include a semantic prefix, as long as the pull request title contains a meaningful encompassing semantic message.
masterbranch will always contain the next major version
masteris always versioned as the next theoretical release branch