¿Qué es versionamiento semántico?

El versionamiento semántico es un estándar a la hora de definir la versión una API pública o una biblioteca en el mundo del software.

Cuando creamos software necesitamos tener una forma de saber si la última versión de una herramienta es un cambio absoluto del comportamiento o solo arregla unos fallos menores, es decir, necesitamos tener una manera de comunicar a nuestros usuarios la naturaleza y el alcance de la última versión que se va a publicar.

¿Cómo se utiliza el versionamiento?

Se compone de 3 cifras de números enteros separados por puntos y que no pueden ser negativos.

1.2.8 // major.minor.patch

Si lo leemos de izquierda a derecha, el primer número (1) se le conoce como “Major”, el segundo número (2) es “Minor” y el último es el que llamamos “Patch” (8).

Estos números se incrementan en 1 cada vez que una biblioteca sufre cambios y se publican. Vamos a entrar más en detalle, ¿qué significa cada uno? ¿cuándo y como utilizamos?

Patch

Es el tercer número (derecha a izquierda), se refiere principalmente a corrección de errores compatibles con versiones anteriores.

1.2.1 // versión actual con errores
1.2.2 // versión nueva con correcciones

Minor

Es el número del centro y se modifica cuando aparecen:

• Corrección de errores y/o mejoras en funcionalidades.
• Nuevas funcionalidades que no son cruciales para el proyecto.

Aunque aumentemos esta versión todos los cambios son compatibles con las anteriores. Si aumentamos nuestra versión “minor” debemos reiniciar el “patch”.

1.2.4 // Versión anterior
1.3.0 // Versión nueva compatible con versiones anteriores, se reinicia el patch

Major

Indica que la biblioteca ha sufrido un gran cambio y que además, ese cambio puede ocasionar errores para la gente que la utiliza. El cambio puede incluir:

• Corrección de errores y/o mejoras en funcionalidades.
• Nuevas características/funcionalidades.

Puede incluir cambios de “minor” y “patch”. Cuando se incrementa la versión “major”, entonces “minor” y “patch” se reinician.

1.3.4 // Versión anterior
2.0.0 // Versión nueva, se reinicia el minor y el patch

¿Cómo empezamos?

La primer version de una API o biblioteca debe comenzar con 0.1.0 y cuando sale producción (primer versión) debe ser 1.0.0

Etiquetas y “Pre-release”

Para utilizarlas se agrega un guion y una palabra (etiqueta) luego del “patch”. Indican que es una version que no esta lista para ser liberada o utilizada en un entorno estable.

1. Alpha

1.0.0-alpha.1

Es una versión inestable que es muy probable que tenga muchas opciones que mejorar, pero queremos que sea probada para encontrar errores y poder poner a prueba funcionalidades, en la mayoría de los casos podemos decir que esta casi listo el producto.

2. Beta

1.0.0-beta.3

“Beta” una versión mas estable que “Alpha” en la que contamos con el producto en su totalidad, y se desea realizar pruebas de rendimiento, usabilidad y funcionamiento de algunos módulos para ver cómo funciona bajo un ambiente no tan controlado.

3. Pre-release

El siguiente paso y último paso es “RC” (Release Candidate), es el último paso del software antes de salir a producción.

1.0.0-rc.3

Ejemplo real del flujo completo

Supongamos que tienes una aplicación estable con la versión 1.4.6, decides empezar el desarrollo de la próxima gran versión, la 2. Entonces los primeros desarrollos en esa versión nueva irán a la 2.0.0, pero como todavía estás empezando y probando cosas, podrías ponerle un identificador que le dijese a la gente la estabilidad de esa versión. Tu versión quedaría en algo como 2.0.0-alpha.1, por ejemplo, y la gente sabría que es una versión “alpha” no muy estable.

1.4.6         // versión estable
2.0.0-alpha.1 // versión en desarrollo

Según fueses avanzando en el desarrollo, llegarías a una versión beta la cual marcarías por ejemplo como 2.1.3-beta.1 (algunos equipos brincan directo a “release candidate” sin pasar por “beta”, es tu decisión). Así hasta que todo estuviese listo para publicarse, y marcases una versión como candidata para ser publicada como 2.1.5-rc.1.

1.4.6         // versión estable
2.0.0-alpha.1 // versión en desarrollo
2.0.0-rc.1    // versión en release candidate (testing)

Una vez cerrado el “release candidate” podemos llevar nuestra biblioteca a producción aumentando la versión a 2.0.0 (Se remueven las etiquetas).

¿Cómo incluir APIs o bibliotecas?

Cuando vamos a utilizar las versiones y queremos incluir bibliotecas en nuestros proyectos podemos hacerlo de distintas formas:

• Exacta: Obtiene una versión especifica de una API o bibilioteca y solo se actualiza si la cambiamos manualmente.
• Cambio de “major”: Se representa con “>” y actualiza el último major, “minor” y “patch” disponibles (Normalmente genera errores cuando cambia el mayor).
• Cambio de “minor”: Se representa con “^” y actualiza el último “minor” y “patch” disponibles (compatible con la versión actual).
• Cambio de “patch”: Se representa con “~” y actualiza el último “minor” disponible (compatible con la versión actual).

Ejemplo:

"biblioteca": "5.21.7"   // versión exacta
"biblioteca": ">5.21.7"  // actualiza a la última versión disponible
"biblioteca": "^5.21.8"  // incrementa la versión minor y/o patch
"biblioteca": "~5.21.8"  // solo cambia el patch