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

Schéma de gestion des versions

Il y a plusieurs changements majeurs par rapport à notre stratégie 1.x décrite ci-dessous. Chaque changement vise à satisfaire les besoins et les priorités des développeurs/mainteneurs et des développeurs d’applications.

1. Utilisation stricte de la spécification SemVer
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

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		mises à jour de correctifs Chromium

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. For more details on which versions are supported, see our Electron Releases doc.

Les lignes plus anciennes ne seront pas prises en charge par le projet Electron, mais d’autres groupes peuvent s’approprier et sauvegarder eux-mêmes les correctifs de stabilité et de sécurité. Nous décourageons cela, mais reconnaissons que cela facilite la vie de nombreux développeurs d'applications.

Versions bêta et corrections de bugs

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é. Pour ce faire, SemVer permet un i_dentificateur de pré-version_ pour indiquer qu’une version particulière n’est pas encore sûre ou 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. Toutes les nouvelles lignes de versions majeures et mineures commencent par une série bêta indiquée par les balises de préversion SemVer de beta.N, par exemple. 2.0.0-beta.1. . Après la première bêta, les versions bêta suivantes doivent remplir toutes les conditions suivantes :
   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. On peut tout à fait admettre des changements de non cassant d'API avant la semaine 3 dans le cycle bêta, et cela même si ces changements ont le potentiel de causer des effets secondaires modérés.
2. Considerer comme valide dans la plupart des étapes du cycle beta, les changements signalés par feature, qui ne modifient pas les chemins de code existants. Les utilisateurs peuvent explicitement activer ces options dans leurs applications.
3. Admettre des fonctionnalités de n'importe quel type après la semaine 3 dans le cycle bêta est 👎 sans une très bonne raison.

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 :

• Une nouvelle branche de version est créée qui comprend les dernières fonctionnalités. Elle est publiée en tant que 2.0.0-beta.1.
• Une correction de bug est apportée dans la branche master pouvant être rétroportée vers la branche de publication. Le patch est appliqué, et une nouvelle version bêta est publiée en tant que 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.
• Plus tard, une faille zero-day étant découverte un correctif est appliqué à la branche master. Nous rétroportons le correctif sur la ligne 2-0-x et publions 2.0.1.

Quelques exemples de la façon dont différentes plages de SemVer vont agir sur les nouvelles versions:

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

• La branche main contiendra toujours la prochaine version majeure X.0.0-nightly.DATE dans son package.json.
• Les branches de version ne sont jamais fusionnées vers main.
• Les branches de version do contiennent la version correcte dans leur package.json.
• Dès qu'une branche de publication est coupée pour une majeur, main doit être repoussé au majeur suivant ( main est toujours versionné comme la prochaine branche de publication théorique).

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.