La gestion de versions d'Electron

Un descriptif de la politique de gestion de version et d'implémentation.

Depuis la version 2.0.0, Electron suit la spécification SemVer. La commande suivante installera la version stable la plus récente d’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

SemVer

Vous trouverez ci-dessous un tableau faisant correspondre explicitement les types de modifications à leur catégorie correspondante de SemVer (par exemple, Majeur, Mineur, 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	Corrections de bugs d'Electron
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		fix-related Chromium patches

Pour plus d’informations, consultez la spécification Semantic Versioning 2.0.0.

Notez que la plupart des mises à jour de Chromium seront considérées comme des ruptures. Les correctifs qui peuvent être rétroportés seront probablement choisis comme correctifs.

Branches de stabilisation

Les branches de stabilisation sont des branches qui fonctionnent parallèlement à main, ne prenant en compte que des commits triés sur le volet liés à la sécurité ou à la stabilité. Ces branches ne sont jamais fusionnées pour revenir à main.

Depuis Electron 8, les branches de stabilisation sont toujours des lignes de version majeures, et nommées par rapport au modèle suivant $MAJOR-x-y par exemple 8-x-y. (Avant cela, nous utilisions lignes de version** mineures **et les nommions comme $MAJOR-$MINOR-x par exemple. 2-0-x.)

Nous permettons à plusieurs branches de stabilisation d’exister simultanément, une pour chaque version prise en charge.

Pour plus de détails sur les versions prises en charge, consultez notre document Versions d'Electron .

Les lignes plus anciennes ne seront pas prises en charge par le projet Electron.

Cycle de publication

Electron follows an 8-week regular release cycle where key milestones correspond to matching dates in the Chromium release cycle.

Exemple

When Electron 41 hits its stable release, the release line for Electron 42 is branched off of main. Its first alpha release is created with all the changes contained on main:

A bug fix comes into main that can be backported to the release branch. The patch is applied, and it is published in the next v42.0.0-alpha.2 release.

The version of Chromium that powers Electron 42 hits Chrome's beta channel. The alpha line is promoted to beta.

Beta releases continue weekly until Electron 42 is promoted to stable and the same cycle starts again with 43-x-y. Later, a zero-day exploit is revealed and a fix is applied to main. We backport the fix to the 42-x-y line and release 42.0.1.

Processus de demande de rétroport

Toutes les lignes de version compatibles accepteront les pull requests externes pour rétroporter les corrections précédemment fusionnées à main, bien que cela doivenbt peut être se faire au cas par cas pour certaines lignes plus anciennes et toujours prises en charge. Toutes les décisions contestées concernant des rétroportages de la ligne de publication seront résolues par le Groupe de travail Releases Working Group en tant qu'élément d'agenda lors de leur réunion hebdomadaire la semaine où la Pull Request de rétroport est posée.

Indicateurs de fonctionnalités

Les indicateurs de fonctionnalité sont 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é

Commits sémantiques

Toutes les pull requests doivent adhérer à la spécification Conventional Commits , qui peut être résumée comme suit:

• Les commits qui entraîneraient un bump SemVer major doivent faire débuter body par BREAKING CHANGE:.
• Les commits qui entraîneraient un bump de type patch doivent commencer par feat:.
• Les commits qui entraîneraient un bump SemVer de type patch doivent commencer par fix:.

Le repository electron/electron impose également la fusion squash, vous devez donc vous assurer que votre demande d'ajout a le préfixe de titre correct.

Branche main versionnée

• 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.
• Les branches de version ne sont jamais fusionnées vers main.
• All package.json values are fixed at 0.0.0-development.

Versionnage historique (Electron 1.X)

Les versions d'Electron < 2.0 n'étaient pas conforme à la spécification SemVer : les versions principales correspondaient aux changements de l'API de l'utilisateur final, les versions mineures correspondaient aux versions majeures de Chromium et les versions correctives correspondaient aux nouvelles fonctionnalités et corrections de bugs. 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. Les cycles de tests QA d'applications importantes comme Slack, Teams, Skype, VS Code, Atom et Github Desktop peuvent être longs et la stabilité est un objectif primordial. 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.