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.
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:
{
"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:
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!: herramienta CLI para la automatización de versionamiento y publicaciones.
- Release Please: herramienta para la automatización de archivos changelog, versionamiento y publicación.
- 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.
Top comments (0)