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

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 SemVer spec
2. Introducción de las etiquetas de semver-compliant -beta
3. Introducción a mensajes de compromiso convencionales
4. Ramas estabilizadoras bien definidas
5. La rama main no tiene versiones: solo las ramas de estabilización contienen información de las versiones

Reseñamos en detalle cómo funcionan las ramas git, cómo funcionan las etiquetas de npm, qué es lo que los desarrolladores esperan ver, y como se pueden portar cambios a versiones anteriores.

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		parches de chromium relacionados con soluciones de problemas

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. Antes de eso nosotros usabamos la lineas de version minor y las nombrabamos como $MAJOR-$MINOR-x p.e. 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. Incitamos que no se haga esto, pero reconocemos que haría la vida de varios desarrolladores de aplicación más fácil.

Beta releases and bug fixes

Los desarrolladores quieren saber cuáles publicaciones son seguras. Hasta características que parecen inocentes pueden introducir grandes regresiones en aplicaciones complejas. Al mismo tiempo, quedarse con una versión arreglada es peligroso porque está ignorando parches de seguridad y arreglos de errores que pudieron salir desde su versión. Nuestra meta es permitir que el siguiente rango semver estandar en package.json :

• Usar ~2.0.0 para admitir solo arreglo relacionados con la estabilidad o seguridad de su publicación 2.0.0.
• Use ^2.0.0 para admitir características no frágiles y razonablemente estables que trabajen tanto en seguridad como en arreglo de errores.

Lo que es importante del segundo punto es que las aplicaciones que usan ^ aún deben ser capaces de esperar cierto nivel de estabilidad. Para lograr esto, SemVer permite un identificador de pre-lanzamiento para indicar que una versión en particular no es segura o estable.

Sin importar lo que elija, periódicamente tendrá que golpear su versión en su package.json como cambios que son un hecho en la vida útil de Chromium.

El proceso es el siguiente:

1. Todos los nuevos lanzamientos de la linea major y minor comienzan con una series de betas indicado por la etiqueta de pre-lanzamiento beta.N de SemVer, p.e. 2.0.0-beta.1. Después de la primera beta, las versiones beta que la sigan deben cumplir con las siguientes condiciones:
   1. El cambio es compatible con API hacia atrás (se permiten las deprecaciones)
   2. El riesgo de cumplir con nuestro cronograma de estabilidad debe ser bajo.
2. Si es necesario hacer cambios permitidos una vez que la versión es beta, se aplican los cambios y la etiqueta prerelease is encrementado, Por ejemplo 2.0.0-beta.2.
3. Si una versión beta en particular es generally regarded como estable, será reenviado como una versión estable, cambiando sólo la información de la versión. p.e. 2.0.0. Después le primera versión estable, todos los cambios deben ser compatibles con versiones anteriores, correcciones de error o de seguridad.
4. Si correcciones futura de errores o parches de seguridad se hacen deben una vez que la versión sea estable, esas correcciones son aplicadas y la versión patch es incrementada, Por ejemplo 2.0.1.

Específicamente, lo anterior significa:

1. Admitir cambios que no generen rompimiento en la API antes de la Semana 3 en el ciclo beta está bien, incluso si esos cambios tienen potencial de causar efectos secundarios moderados.
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.

Por cada cambio mayor y menor, debería esperar ver algo como lo siguiente:

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 ejemplo del ciclo de vida en imágenes:

• 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.
• El beta es considerado generalmente estable y es publicado de nuevo como no-beta con el nombre 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.

Algunos ejemplos de como varios rangos SemVer recogerán los nuevos lanzamientos:

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

• La rama main siempre contendrá la siguiente versión mayor X.0.0-nightly.DATE en su package.json.
• Release branches are never merged back to main.
• Las ramas de versión _do_contienen la versión correcta en su 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)

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, Skype, 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.