SemVer: Qué es y por qué es importante para el desarrollo de software
Tags: spanish, opensource, programming, semver
Published: 2023-04-06 05:11:33

## Introducción

En el mundo del desarrollo de software, la gestión de versiones es un aspecto fundamental para garantizar la calidad y la compatibilidad del software. A continuación veremos como funcionan estas versiones y como podemos aplicarla a nuestros proyectos.

## ¿Qué es SemVer?

El Versionamiento Semantico o **SemVer** por su nombre en inglés (Semantic Versioning), es una de las convenciones de nomenclatura de versiones más populares para entender las versiones de un software, que proporciona una manera semántica y consistente etiquetas para rastrear las versiones de un proyecto de software.

Esta nomenclatura nos permite conocer el estado de una aplicación de manera simple y la podemos encontrar como una serie de número dividido en tres grupos separados por un punto. Cada grupo se conoce como mayor, menor y parche respectivamente (_major_, _minor_ y _patch_ en inglés o también como _x_, _y_, _z_), por ejemplo: _1.0.1_, _2.1.0_, _14.2.9_, etc…

Cada uno de estos grupos sirve para describir un estado diferente en el proceso de desarrollo:

- Patch: el cambio de este número representa una reparación en el código. Esta actualización se realiza siempre que se soluciona un error en el código para asegura su estabilidad y seguridad, por ejemplo: `1.0.1` → `1.0.2`, `2.1.0` → `2.1.1`, `14.2.9` → `14.2.10`.

- Menor: este número representa una característica nueva, lo que implica que la actualización es segura y agrega una funcionalidad o comportamiento nuevo que se puede implementar. Al agregar una característica nueva se actualiza este grupo y el número de patch pasa a cero, por ejemplo: `1.0.1` → `1.1.0`, `2.1.0` → `2.2.0`, `14.2.9` → `14.3.0`.

- Major: cuando este número cambia está representando una ruptura, lo que implica que dicha actualización causará daños en el código ya que esta versión o es compatible con versiones anteriores. La actualización de este grupo requiere que los números tanto de menor como de patch sean restaurados a cero, por ejemplo: `1.0.1` → `2.0.0`, `2.1.0` → `3.0.0`, `14.2.9` → `15.0.0`.

También es posible encontrar información acerca de la estabilidad de un proyecto como un dato adicional en el path:

- Dev: esta etiqueta hace referencia a un código que aún se encuentra en un estado de desarrollo. Ejemplo: `1.0.1-dev`, `2.1.0-dev`, `14.2.9-dev`.

- Alpha: es la primera etapa de código que se prepara para ser parte de un release. Ejemplo: `1.0.1-alpha`, `2.1.0-alpha`, `14.2.9-alpha`.

- Beta: es una versión más estable pero que aún no cumple con la estabilidad suficiente para ser un release. Ejemplo: `1.0.1-beta`, `2.1.0-beta`, `14.2.9-beta`.

- RC1: esta versión es una posible candidata a un para un release, aun siendo un pre-release cuenta con una gran estabilidad. Ejemplo: `1.0.1-RC1`, `2.1.0-RC1`, `14.2.9-RC1`.

- RC2: aun cuando esta versión es un pre-release, es la más estable y cercana al release. Ejemplo: `1.0.1-RC2`, `2.1.0-RC2`, `14.2.9-RC2`.

- Stable: esta versión tiene toda la estabilidad y se considera como release, por el mismo motivo no requiere ser agregada en la etiqueta semántica ya que incurriría en una redundancia. Ejemplo: `1.0.1`, `2.1.0`, `14.2.9`.

Todas aquellas versiones inferiores a la _1.0.0_ también son consideradas como pre-releases.

Según esta nomenclatura, un proyecto iniciaría con un mínimo de una característica lo que implica que la versión mínima sería _0.1.0_, de la misma manera, si un proyecto o producto ya se encuentra en producción su versión mínima sería _1.0.0_.

## ¿Por qué es importante SemVer en el desarrollo de software?

Ya que SemVer es una convención popular, al aplicarla a cualquier desarrollo mostrará el estado un software de manera rápida a las personas que contribuyen en él, al mismo tiempo que es posible crear o encontrar documentación que apoyan este tipo de versionamiento como son los llamados archivos de cambios o [`changelog`]([https://keepachangelog.com/](https://keepachangelog.com/en/1.0.0/)).

SemVer también es usado por muchos gestores de dependencias como `npm` , `composer` , `maven` , entre otros; para describir el estado de las dependencias de un proyecto y sirve como apoyo a los grupos de desarrollo en cuanto a los beneficios o desventajas que se pueden encontrar al actualizar estas dependencias.

## Cómo funciona SemVer en los gestores de dependencias

En muchos de los proyectos #OpenSource integran SemVer a través de etiquetas semánticas, las cuales podemos encontrar ordenadas de la versión más alta a la más baja y hacen referencia a un punto especifico del código.

```
## v1.1.0

on Mar 7, 2023

- commit: 606e572

## v1.0.0

on Mar 1, 2023

- commit: e02581f

## v0.3.1

on Feb 16, 2023

- commit: d194c2e

## v0.3.0

on Feb 15, 2023

- commit: 570045b

## v0.3.0-RC2

on Feb 14, 2023

- commit: 28fe4ec

## v0.3.0-RC1

on Feb 12, 2023

- commit: ecffd4c
```

Basado la información de estas etiquetas y algunos operadores matemáticos y lógicos, los gestores de dependencias son capaces de detectar las condiciones y restricciones para la instalación y actualización de las dependencias.

Las restricciones que se pueden encontrar son:

- Restricción de versión exacta: define una versión exacta a instalar de un paquete. Ejemplo `"someone/my-package": "2.1.3"` instalará la versión 2.1.3.

- Rango de versiones: es posible definir un rango superior e inferior para la instalación de una dependencia. Ejemplo: `"someone/my-package": ">=2.1.0 || <2.2.0"` instalará cualquier versión entre la 2.1.0 y 2.2.0.

- Intervalo de versiones con guiones: al igual que la restricción por rango podemos definir los límites de esta restricción separados por un guion. Ejemplo `"someone/my-package": "2.1.0 - 2.3.0"` instalará cualquier versión entre la 2.1.0 y 2.3.0.

- Rango de versión comodín: este restricción está provista con un comodín o wildcard para definir el rango de instalación de manera simple. Ejemplo: `"someone/my-package": "2.1.*"` instalará cualquier versión desde la 2.1.0 hasta la 2.1.n disponible, `"someone/my-package": "2.*"` instalará cualquier versión desde la 2.0.0 hasta la 2.n disponible.

- Rango de versiones de tilde: el comportamiento de esta restricción es similar al uso de wildcard, sin embargo hace uso de una tilde o virgulilla para definir su rango. Ejemplo `"someone/my-package": "~2.1.0"` instalará cualquier versión superior o igual a 2.1.0 e inferior a 2.2.0, `"someone/my-package": "~2.1"` instalará cualquier versión superior o igual a 2.1.0 e inferior a la 3.0.0.

- Rango de versión de caret: esta versión mejorada hace uso de un acento o caret realizará una instalación que no rompa con la estabilidad del proyecto. Ejemplo: `"someone/my-package": "^2.1.0"` instalará cualquier versión superior o igual 2.1.0 e inferior a 3.0.0 ya que este cambio puede generar rupturas de código.

También debemos tener en cuenta que los gestores de dependencias están en la capacidad de instalar versiones de desarrollo o pre-release dentro de los rangos definidos y dependiendo de su configuración.

## Cómo implementar SemVer en un proyecto de software

Ya sea que deseemos o no publicar nuestro proyecto, los gestores de dependencias cuentan con una etiqueta para llevar el versionamiento de nuestro software, como ocurre en el caso de `npm`:

```JSON
{
  "name": "test",
  "version": "1.0.0", // Etiqueta para uso de SemVer
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}
```

Git y plataformas como GitHub también nos permite agregar etiquetas con las cuales podemos hacer referencia a nuestro código:

```Shell
git tag -a v1.0.0 -m "version 1.0.0" <commit_sha>
```

También existe herramientas que nos pueden facilitar la publicación de versiones en nuestro código, algunos ejemplos para proyectos con javascript:

- [Release It!](https://github.com/release-it/release-it): herramienta CLI para la automatización de versionamiento y publicaciones.
- [Release Please](https://github.com/googleapis/release-please): herramienta para la automatización de archivos changelog, versionamiento y publicación.
- [Sui](https://github.com/SUI-Components/sui): paquete para gestión de commits y releases en proyectos monorepo.

## Conclusión

En resumen, SemVer es una convención de nomenclatura de versiones que se utiliza para etiquetar y rastrear las versiones de un proyecto de software de manera semántica y consistente. Es importante para el desarrollo de software porque ayuda a los desarrolladores y usuarios a comprender los cambios en una nueva versión del software y a gestionar la compatibilidad del software. Implementar SemVer en un proyecto de software es una práctica recomendada para garantizar la calidad y la compatibilidad del software.