El versionamiento semántico, como se le conoce en español hace referencia a esos números que suelen aparecer junto a los nombres de las librerías que usamos cuando desarrollamos. Contrario a lo que yo pensaba hasta hace algunos años, muchas veces estos números no son elegidos al capricho del desarrollador, sino que tienen un significado bastante importante cuando de relacionar bibliotecas de software se trata.

El versionado semántico divide el número de cada versión en tres segmentos numéricos, que tienen el propósito de indicar el estado y la compatibilidad de una pieza de software. Imagínate que esta es una librería que tiene un par de entradas:

Comenzando por la parte más pequeña o conocida como el segmento de los parches, este pequeño número se usa para indicar que, mientras que la biblioteca se actualizó, no se está introduciendo nueva funcionalidad en ella. Comúnmente se usa cuando se corrigen errores dentro de esta o cualquier otro cambio que no modifique la apariencia "externa" de nuestra API. Se entiende que esta puede estarse moviendo con rapidez a medida que resuelves errores o casos excepcionales en tu código. Eso quiere decir que yo podría cambiar lo que quisiera acá dentro, mientras que no modifique nada de afuera y todo siga funcionando. Cada una de estas modificaciones que publique, aumentará la versión de parche.

Luego, sigue el segmento de los cambios menores o características. Este se usa para indicar que se le ha añadido funcionalidad nueva a la biblioteca pero que nada de lo anterior dejará de funcionar de la manera en la que ya lo hace. Es decir mientras que la apariencia exterior de la biblioteca versionada ha cambiado, lo que antes se conectaba con ella, puede seguir haciéndolo sin problema. Volviendo a mi ejemplo, podría cambiar el punto de conexión de uno de estos, a uno de estos, ahora mi caja soporta nuevas funcionalidades, a través de esta nueva entrada, sin embargo, todo lo demás sigue funcionando. Si la versión menor cambia, en número de parches debe ser reestablecido a 0.

Por último, tenemos el componente de cambios mayores o el de ruptura. Este se emplea para indicar cambios tanto externos como internos que resultan en hacer nuestro software no sea compatible con versiones anteriores. Este se llama de ruptura puesto que si la persona que usa nuestra biblioteca actualiza descuidadamente la versión, probablemente encontrará muchos errores y cosas inservibles en su código. Este cambio, en términos de mi ejemplo sería como cambiar el punto de conexión, de esta a… esta, la conexión británica, en teoría mi software seguirá funcionando más o menos igual a como lo hacía antes, sin embargo, será incompatible con versiones pasadas.

Existen 11 principios que se deben observar cuando usamos semver pero la más importante es que una vez liberada una versión de software no debemos modificar su contenido sin aumentar también el número de la versión, así sea la corrección al más pequeño error en la versión liberada, si lo corriges, tienes que publicar una nueva versión.

Idealmente, SemVer está pensado para sofrware que define una API, puesto que, es basándose en esa API es que se dará el versionamiento. El desarrollo inicial de esta API debe comenzar a partir de la versión 0.1.0, ya que el 1 de la versión menor indica que comenzamos ya con un set definido de operaciones. Y una vez que estamos listos para producción, debemos brincar a la versión 1.0.0.

Por otro lado, si estás desarrollando nueva funcionalidad y quieres liberarla de alguna forma sin afectar a aquellas personas que ya trabajan con una versión estable de tu software, basta con agregarle como sufijo a los tres dígitos un guión seguido de una etiqueta, lo cual indica que esa versión de la librería es una versión pre-release o pre-liberación. Con lo cual, aquellas personas que quieran usar cosas estables podrán ignorar tranquilamente.