El tema que vamos a tratar hoy no sólo afecta a GO sino que es un tema que se trata en general en el mundo del software. Y va íntimamente ligado al tema de dependencias que llevamos tratando durante el pasado mes de Enero.
¿Por qué existe el Semantic Versioning?
Cuando Go Modules hace su magia y nos baja las dependencias que tiene nuestro proyecto, modifica y añade las líneas necesarias de dichas dependencias al fichero go.mod el cual queda similar:
module github.com/aperezg/monster
require (
github.com/google/jsonapi v0.0.0-20181016150055-d0428f63eb51
github.com/gorilla/mux v1.7.0
github.com/oklog/ulid v1.3.1
)
Si nos fijamos en el apartado de require podemos ver que las dependencias necesarias para nuestro proyecto son:
- github.com/google/jsonapi
- github.com/gorilla/mux
- github.com/oklog/ulid
Pero además cada una indica una version determinada, con la letra v. Esto es muy importante porque imaginemos que no tuviéramos versiones y no tuviéramos forma de obtener o mantener en nuestro proyecto la versión del código que nos fuera correcta, sería una locura, estaríamos constantemente adaptando nuestro código para que funcionara.
Pero uno de los co-fundadores de Github y creador de Gravatar, Tom Preston-Werner, tuvo a bien diseñar una especificación muy sencilla para evitar que no se desatara el infierno en la Tierra.
Especificación de Semantic Versioning (Sem ver)
Como podemos ver en la imagen anterior la especificación de Sem ver se divide básicamente en tres, entendamos como funciona cada una de sus partes.
Patch version
Muchos olvidan la importancia o la existencia del Patch o bien tienden a llamarlo Minor pero son cosas distintas.
Subiremos la versión de nuestro Patch siempre y cuando lo que cambiemos en el código sea un bug fix, es decir un comportamiento no esperado o erróneo en el código actual, el cual debe de mantener la compatibilidad con versiones anteriores. Si por cualquier motivo el bug que estamos arreglando hiciera que la librería ya no fuera compatible, es decir que los que la utilizan tengan que hacer un refactor en su código para poder seguir utilizándola, tendríamos que cambiar de Major como ya veremos luego.
Minor version
La parte Minor de nuestra versión es una de las más utilizadas durante el desarrollo de una nueva librería, ya que lo que nos permite es informar de que hemos añadido funcionalidades que antes no existían en la misma, pero que estos cambios siguen siendo compatibles con las versiones anteriores.
Además cuando empecemos una nueva librería ésta empezará en v0.1.0
Igual que comentamos con el Patch si por cualquier motivo la funcionalidad añadida modifica el comportamiento de la librería y obliga a la gente que la utiliza a tener que hacer modificaciones en su código, indicará que debemos de modificar nuestra Major
Major version
Como venimos comentando durante las dos partes anteriores subiremos la versión de nuestra Major siempre que tengamos que lanzar un cambio en nuestro código que nos provoque no poder mantener la compatibilidad con las versiones anteriores. A esto lo llamamos breaking changes
Tenemos que tener cuidado de no caer en la tentación de ir incrementando este valor de manera alocada, es decir mientras más podamos aguantar sólo subiendo Patch y Minor mejor, ya que evitará que la gente que utiliza nuestras librerías tengan que realizar cambios en su código para adaptarse a la nueva versión.
Se puede dar el caso de que sin querer subamos una Minor o Patch que rompa la compatibilidad, en cuyo caso no crearemos una Major, sino que arreglaremos el código para recuperar la compatibilidad y sacaremos una Minor lo antes posible informando a los usuarios del problema.
Y hasta aquí el tema de Semantic Versioning esperamos que os haya resultado útil, y comprendáis mejor como funcionan las versiones, si queréis que profundicemos en como realizar este control de versiones de nuestras librerías con Git y Go Modules dejadlo en los comentarios o pedirlo por Twitter
adrianpgl
aperezg