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

npm install --save-dev electron

Yarn

yarn add --dev electron

Pour mettre à jour un projet existant afin d'utiliser la dernière version stable :

npm

npm install --save-dev electron@latest

Yarn

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.

1. Strict use of the the SemVer spec
2. Introduction de semver compatible avec les tags -beta
3. Introduction des messages de commit conventionnels
4. Branches de stabilisation bien définies
5. 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 version 2.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:

1. 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:
   1. Le changement est compatible avec l'API ascendante (les dépréciations sont autorisées)
   2. Le risque de respect de notre calendrier de stabilité doit être faible.
2. 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.
3. 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é.
4. 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 :

1. 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.
2. 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.
3. 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 release 2.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 majeure X.0.0-nightly.DATE dans son package.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.