Versionado de Electron

Una mirada detallada en la política e implementación de las versiones.

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

Para actualizar un proyecto existente para que use la última versión estable:

npm

npm install --save-dev electron@latest

Yarn

yarn add --dev electron@latest

SemVer

A continuación una tabla que mapea explícitamente los tipos de cambios con sus correspondiente categoría de SemVer (p. e. Major, Minor, Patch).

Incrementos de versiones major	Incrementos de version minor	Incrementos en la versión patch
Cambios incompatibles con la API de Electron	Cambios compatibles de la API de Electron	Solución a fallos de Electron
Actualizaciones en la version major de Node.js	Actualizaciones en la version minor de Node.js	Actualizaciones en la version patch de Node.js
Actualización de versiones de Chromium		fix-related Chromium patches

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.

Desde Electron 8, las ramas de estabilización son siempre de las líneas de versión mayor y se nombran contra la siguiente plantilla $MAJOR-x-y p.e. 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.

[!TIP] For more details on which versions are supported, see our Electron Releases doc.

Older lines will not be supported by the Electron project.

Release cycle

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

Ejemplo

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.

Backport request process

Todas las versiones soportadas aceptarán peticiones de pull requests externas a backport correcciones previamente fusionadas en main, aunque esto puede ser caso por caso para algunas versiones mas antiguas. 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

Banderas de características son prácticas comunes en Chromium, y son bien establecidas en el ecosistema de diseño web. En el contexto de Electron, banderas de características o ramas suaves deben seguir las siguientes propiedades:

• está habilitado/deshabilitado en tiempo de ejecución o en tiempo de construcción, no soportamos el concepto de una bandera de característica alcance por solicitud
• segmenta completamente nuevos y viejos rutas de códigos; refactorizando viejo código para soportar nuevas características viola el contrato de las banderas de características
• las banderas de características eventualmente son removidas después de que la característica es lanzada

Semantic commits

All pull requests must adhere to the Conventional Commits spec, which can be summarized as follows:

• Los commits que resultarían en una versión major de SemVer deben empezar sus cuerpos con BREAKING CHANGE:.
• Los commits que resultarían en una versión minor de SemVer debe empezar con feat:.
• Los commits que resultarían en una versión patch de SemVer deben empezar con 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

• 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.
• Release branches are never merged back to main.
• All package.json values are fixed at 0.0.0-development.

Historical versioning (Electron 1.X)

Las versiones < 2.0 de Electron no se ajustaban a las especificaciones de SemVer: las versiones major correspondían a los cambios en la API del usuario final, las versiones minor correspondían a las versiones major de Chromium y las versiones patch correspondían a las nuevas características y correcciones de errores. Mientras que es conveniente para los desarrolladores combinar características, crea problemas para los desarrolladores de aplicaciones orientadas al cliente. The QA testing cycles of major apps like Slack, Teams, VS Code, and GitHub Desktop can be lengthy and stability is a highly desired outcome. Hay un riesgo grande adoptando nuevas características mientras se está tratando de asimilar las soluciones de errores.

Aquí hay un ejemplo de la estrategia 1.x:

Una aplicación desarrollada con 1.8.1 no puede tener la solución de errores 1.8.3 sin asimilar las características 1.8.2, o portando la solución y manteniendo un nueva línea de publicación.