La gestion de versions d'Electron
Un descriptif de la politique de gestion de version et d'implémentation.
As of version 2.0.0, Electron follows the SemVer spec. The following command will install the most recent stable build of Electron:
- npm
- Yarn
npm install --save-dev electron
yarn add --dev electron
Pour mettre à jour un projet existant afin d'utiliser la dernière version stable :
- npm
- Yarn
npm install --save-dev electron@latest
yarn add --dev electron@latest
Versioning scheme
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.
- Strict use of the the SemVer spec
- Introduction de semver compatible avec les tags
-beta
- Introduction des messages de commit conventionnels
- Branches de stabilisation bien définies
- La branche
main
est sans version; seules les branches de stabilisation contiennent des informations de version
Nous expliquerons en détail comment les branches de git fonctionnent, comment le tagging npm fonctionne, ce que les développeurs devraient d'attendre à voir, et comment l'on peut rapporter les changements antérieurement.
SemVer
Below is a table explicitly mapping types of changes to their corresponding category of SemVer (e.g. Major, Minor, Patch).
Incréments de version Majeure | Incréments de version mineure | Incréments de version de Correctifs |
---|---|---|
changement Electron qui altère l'API | changement Electron n'altérant pas l'API | Electron bug fixes |
Mises à jour de la version majeure de Node.js | Mises à jour mineure de la version de Node.js | Mises à jour des correctifs de Node.js |
mises à jour de version Chromium | mises à jour de correctifs Chromium |
For more information, see the Semantic Versioning 2.0.0 spec.
Note that most Chromium updates will be considered breaking. Fixes that can be backported will likely be cherry-picked as patches.
Stabilization branches
Stabilization branches are branches that run parallel to main
, taking in only cherry-picked commits that are related to security or stability. These branches are never merged back to main
.
Since Electron 8, stabilization branches are always major version lines, and named against the following template $MAJOR-x-y
e.g. 8-x-y
. Prior to that we used minor version lines and named them as $MAJOR-$MINOR-x
e.g. 2-0-x
.
We allow for multiple stabilization branches to exist simultaneously, one for each supported version. For more details on which versions are supported, see our Electron Releases doc.
Older lines will not be supported by the Electron project, but other groups can take ownership and backport stability and security fixes on their own. Nous décourageons cela, mais reconnaissons que cela facilite la vie de nombreux développeurs d'applications.
Beta releases and bug fixes
Les développeurs veulent savoir quelles versions sont fiables (safe). Même des fonctionnalités apparemment innocentes peuvent introduire des régressions dans des applications complexes. En même temps, verrouiller une version corrigée est dangereux parce que vous ignorez les correctifs de sécurité et les corrections de bogues qui sont peut-être apparues depuis votre version. Notre objectif est d'autoriser les plages de semver standards suivantes dans package.json
:
- Utilisez
~2.0.0
pour admettre que les corrections liées à la stabilité ou à la sécurité dans votre version2.0.0
. - Utilisez
^2.0.0
pour admettre que la fonctionnalité raisonnablement stable ne soit pas cassée, ainsi que la sécurité et les corrections de bogues.
Ce qui est important dans le deuxième point, c'est que les applications utilisant ^
devraient quand même pouvoir s'attendre à un niveau raisonnable de stabilité. To accomplish this, SemVer allows for a pre-release identifier to indicate a particular version is not yet safe or stable.
Quoi que vous choisissiez, vous devrez périodiquement remonter la version dans votre package.json
car les changements cassés sont un fait de la vie de Chromium.
Le processus est le suivant:
- All new major and minor releases lines begin with a beta series indicated by SemVer prerelease tags of
beta.N
, e.g.2.0.0-beta.1
. After the first beta, subsequent beta releases must meet all of the following conditions:- Le changement est compatible avec l'API ascendante (les dépréciations sont autorisées)
- Le risque de respect de notre calendrier de stabilité doit être faible.
- Si les modifications autorisées doivent être apportées une fois qu'une version est bêta, elles sont appliquées et la balise de prélocation est incrémentée, par exemple
2.0.0-beta.2
. - Si une version bêta particulière est généralement considérée comme stable, elle sera relancée comme une version stable, ne changeant que les informations de version. par exemple
2.0.0
. Après la première stable, tous les changements doivent être des bogues rétrocompatibles ou des corrections de sécurité. - Si de futures corrections de bogues ou de correctifs de sécurité doivent être faites une fois qu'une version est stable, elles sont appliquées et la version patch est incrémentée e. .
2.0.1
.
Plus précisément, ce qui précède signifie :
- Admitting non-breaking-API changes before Week 3 in the beta cycle is okay, even if those changes have the potential to cause moderate side-effects.
- Admitting feature-flagged changes, that do not otherwise alter existing code paths, at most points in the beta cycle is okay. Users can explicitly enable those flags in their apps.
- Admitting features of any sort after Week 3 in the beta cycle is 👎 without a very good reason.
Pour chaque bosse majeure et mineure, vous devriez vous attendre à voir quelque chose comme ceci:
2.0.0-beta.1
2.0.0-beta.2
2.0.0-beta.3
2.0.0
2.0.1
2.0.2
Un exemple de cycle de vie dans les images :
- A new release branch is created that includes the latest set of features. It is published as
2.0.0-beta.1
. - A bug fix comes into master that can be backported to the release branch. The patch is applied, and a new beta is published as
2.0.0-beta.2
. - La bêta est considérée comme généralement stable et est à nouveau publiée comme non-bêta sous
2.0.0
. - Later, a zero-day exploit is revealed and a fix is applied to master. We backport the fix to the
2-0-x
line and release2.0.1
.
A few examples of how various SemVer ranges will pick up new releases:
Backport request process
All supported release lines will 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. All contested decisions around release line backports will be resolved by the Releases Working Group as an agenda item at their weekly meeting the week the backport PR is raised.
Feature flags
Les drapeaux de fonctionnalités sont une pratique courante dans Chromium, et sont bien établis dans l'écosystème de développement Web. Dans le contexte d'Electron, une fonctionnalité ou une branche soft doit avoir les propriétés suivantes :
- il est activé/désactivé soit au moment de l'exécution, soit au moment de la construction ; nous ne prenons pas en charge le concept d'une fonctionnalité à portée de requête
- il segmente complètement les chemins de code nouveaux et anciens; refactoring l'ancien code pour supporter une nouvelle fonctionnalité violation le contrat de trait-flag
- les drapeaux de fonctionnalités sont éventuellement supprimés après la publication de la fonctionnalité
Semantic commits
All pull requests must 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
BREAKING CHANGE:
. - Commits that would result in a SemVer minor bump must start with
feat:
. - Commits that would result in a SemVer patch bump must start with
fix:
.
The electron/electron
repository also enforces squash merging, so you only need to make sure that your pull request has the correct title prefix.
Versioned main
branch
- La branche
main
contiendra toujours la prochaine version majeureX.0.0-nightly.DATE
dans sonpackage.json
. - Release branches are never merged back to
main
. - Les branches de version do contiennent la version correcte dans leur
package.json
. - As soon as a release branch is cut for a major,
main
must be bumped to the next major (i.e.main
is always versioned as the next theoretical release branch).
Historical versioning (Electron 1.X)
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. Bien que pratique pour les développeurs qui fusionnent des fonctionnalités, cela crée des problèmes pour les développeurs d'applications côté client. The QA testing cycles of major apps like Slack, Teams, Skype, VS Code, and GitHub Desktop can be lengthy and stability is a highly desired outcome. Il y a un grand risque d'inclure de nouvelles fonctionnalités en tentant de récupérer des correctifs.
Voici un exemple de la stratégie 1.x :
Une application développée avec la 1.8.1
ne peut pas avoir les corrections d'anomalies de la 1.8.3
sans inclure la fonctionnalité de la 1.8.2
, ou faire un rétroportage de la correction tout en maintenant une nouvelle ligne de versionnage.