Versionado semántico

El versionado semántico es un esquema de versionado que transmite información sobre el código subyacente y sobre qué ha cambiado de una versión a la siguiente. Ayuda a los desarrolladores a entender el impacto de actualizar a una versión nueva de una biblioteca o aplicación.

El versionado semántico se basa en estos principios:

1. Formato del número de versión. El versionado semántico usa un número de versión de tres partes con el formato MAJOR.MINOR.PATCH. Por ejemplo, 2.1.7 especifica la versión mayor #2, la versión menor #1 y el parche #7.

2. Compatibilidad hacia atrás. Una versión nueva MINOR o PATCH debería ser compatible hacia atrás con la versión anterior. Esto significa que el código escrito para una versión más antigua debería funcionar con la versión nueva sin modificaciones.

3. Incremento del número de versión. Al hacer cambios en una biblioteca o aplicación, el número de versión debería incrementarse según el tipo de cambio:

• Versión mayor: Se incrementa cuando se hacen cambios incompatibles en la API.
• Versión menor: Se incrementa cuando se añade funcionalidad de forma compatible hacia atrás.
• Versión de parche: Se incrementa cuando se corrigen bugs de forma compatible hacia atrás.

Imagina que tienes una biblioteca con la versión 1.2.3. Si haces un cambio que añade funcionalidad nueva de forma compatible hacia atrás, incrementarías la versión a 1.3.0. Si haces un cambio que corrige un bug de forma compatible hacia atrás, incrementarías la versión a 1.2.4. Si haces un cambio que introduce una modificación incompatible en la API y obliga a quienes ya usan tu biblioteca a cambiar algo en su código, incrementarías la versión a 2.0.0.

El concepto de versionado semántico está integrado en gestores de paquetes modernos, como npm, pip, composer y otros. Cuando añades una biblioteca de terceros a tu proyecto, puedes especificar un rango de versiones para asegurarte de recibir las últimas correcciones de bugs y funcionalidades sin romper tu código por cambios incompatibles. Por ejemplo, si especificas el rango de versiones ^1.2.3, recibirás cualquier versión que sea 1.x.x y tenga una versión de parche de al menos 3. Esto permite obtener automáticamente las últimas versiones de parche y menores sin cambios incompatibles.

Otros tipos de números de versión y etiquetas

Además de las versiones numéricas, en el mundo del software también puedes encontrarte con otros tipos de versiones, números y etiquetas:

• Número de build: Una build es el proceso de transformar código fuente en un programa ejecutable o una biblioteca. Compilar el código, ejecutar tests y empaquetar el resultado en un formato distribuible forman parte del proceso de build. Cuanto más complejo es el software, más pasos intervienen en ese proceso. En algo como un sistema operativo, la build puede tardar horas o incluso días. La propia infraestructura de build puede ser bastante compleja y causar bugs en el producto final, así que es importante tener un historial de builds y poder reproducirlas. Por eso, en proyectos de software complejos, cada build recibe un número de build único. Los números de build suelen ser secuenciales y sirven para identificar una build concreta del software. Por ejemplo, 1.0.0-build123 se refiere a la build número 123 de la versión 1.0.0. Los números de build suelen usarse internamente por los equipos de desarrollo y no se muestran a los usuarios finales; aun así, puedes verlos en algunos programas.

• Nightly: Versiones que se construyen automáticamente cada noche a partir del código más reciente del repositorio (por ejemplo, 1.0.0-nightly.20220315). Las versiones nightly suelen ir acompañadas de una fecha o de un número de build. Normalmente las usan los desarrolladores para probar las últimas funcionalidades y correcciones de bugs, y para informar de problemas al equipo de desarrollo.

• Alpha: Versiones que siguen en desarrollo activo y todavía no son estables (por ejemplo, 1.0.0-alpha.35). Suelen publicarse para recibir feedback temprano de los usuarios. Cualquier build nightly puede promocionarse a una versión alpha si se considera lo bastante estable para probarla.

• Beta: Versiones que están más o menos terminadas y son estables, pero todavía no se consideran listas para producción (por ejemplo, 1.0.0-beta.1). Suelen publicarse para un grupo seleccionado de usuarios (llamados beta testers), normalmente voluntarios o empleados, para probar el software en condiciones reales y pulir los bugs que queden.

• Release Candidate (RC): Versiones que se consideran estables y listas para producción, pero que todavía tienen que probarse con una audiencia más amplia (por ejemplo, 1.0.0-rc.1). Suelen hacerse públicas para recibir feedback de un grupo mayor de usuarios. Si no se encuentran problemas importantes, la versión RC se promociona a la versión final.

• Stable: Versiones que se consideran estables y listas para producción (por ejemplo, 1.0.0). Se hacen públicas y se recomiendan para uso general.

• LTS (Long-Term Support): Versiones con soporte durante un periodo de tiempo prolongado (por ejemplo, 1.0.0-lts). Normalmente se mantienen durante varios años y reciben actualizaciones de seguridad y correcciones de bugs. Por supuesto, no todo el software tiene o necesita versiones LTS. Son más comunes en piezas grandes de software, como bibliotecas, frameworks o sistemas operativos muy usados en entornos de producción. Quienes usan este software en producción necesitan tener claro que pueden confiar en él durante mucho tiempo y que recibirá actualizaciones de seguridad y correcciones de bugs.