Versionando tu Software

Hoy escribo un post corto pero creo que interesante. Cuando estamos haciendo software (una aplicación móvil, web, API, etc), ¿cómo la versionamos?. Es decir, ¿cómo distinguimos y hacemos explícito hacia el exterior las diferentes versiones que puedan existir?.

Versionar correctamente un producto a lo largo de su ciclo de vida, pudiendo tener trazabilidad sobré que versión (con qué funcionalidad) está o estaba desplegada en qué lugar se considera una práctica fundamental de ingeniería de software.

Aunque existen diferentes metodologías, personalmente me gusta trabajar con versionado semántico.

No es la primera vez que hablo de ello en este blog, pero creo que puede ser interesante escribir un post dedicado a este tema ya que es un problema con el que muchas veces nos encontramos y resolverlo rápido y bien nos va a ahorrar muchos dolores de cabeza.

La idea principal es que cada versión esté conformada por 3 números:

• MAYOR.MINOR.PATCH (por ejemplo v0.2.1)

De forma que el número de PATCH aumenta según se van resolviendo bugs y errores. Si una rama corrige 1 o 10 errores (da igual el número) sin añadir funcionalidad nueva a la aplicación, su versión mantendrá el número MAYOR y MINOR pero aumentará el PATCH, por ejemplo v0.2.9 -> v0.2.10

Si el cambio incluye funcionalidad nueva (aunque también solucione errores), subiría la versión MINOR y se resetearía a 0 el PATCH, por ejemplo v0.2.7 -> v0.3.0.

La versión MAYOR se subirá (reseteando MINOR y PATCH) cuando se rompa el funcionamiento de la versión actual (por ejemplo un cambio de API) y normalmente coincide con la consecución de un hito significativo del proyecto; pasaríamos de v0.2.7 a v1.0.0.

Con estas sencillas reglas, no sólo tú podrás identificar fácilmente tu software sino que estarás siguiendo un formato común y estándar que podrán entender tus clientes o usuarios.

Si yo estoy usando la versión 1.1.0 de una librería y veo que existe una nueva versión 1.2.0, sé que esta no debería romper nada de la 1.1.0 sino simplemente añadir nueva funcionalidad que puedo usar yo o no. Si en vez de la 1.2.0 viese que la nueva versión es la 1.1.1, sabría que también es una versión segura, entendiendo por segura que subir a esa versión desde la mía no romperá nada ya que simplemente es una corrección de algún bug interno.

Sin embargo, si uso la 1.1.0 y de repente aparece la 2.0.0, esta subida de versión ya no se considera segura en tanto en cuanto el cambiar el valor MAYOR nos indica que la nueva versión está "rompiendo" el API pre-existente en la versión anterior y por tanto podría estar afectando a nuestra integración. A veces el cambio en el API se produce en alguna funcionalidad que no estamos usando por lo que es transparente a nosotros pero no podemos asegurar que así sea, por lo que deberemos proceder con precaución y probar que todo sigue funcionando correctamente si decidimos subir de versión.

Estrategias claras de versionado como esta, no sólo son entendibles por nosotros como humanos sino también por máquinas y por tanto son susceptible a su automatización como veíamos en mi post dedicado a cómo automatizar el versionado y publicación de proyectos Javascript.

Personalmente empleo esta estrategia, automatizándola siempre que puedo, tanto para proyectos profesionales como personales y mi experiencia es muy positiva por lo que si no lo haces ya, sí, sin duda te recomiendo que incluyas el versionado dentro de conjunto de buenas prácticas; tarde o temprano, creo que lo vas a necesitar.

Un saludo,

Ricardo