Semantic Versioning 2.0 (SemVer 2.0): ¿Qué es y para que sirve?

Desarrollar APIs no es lo mismo que escribir libros, cuando tu libro pasa por la imprenta ahí suele quedarse, tal como salió -salvo erratas graves- hasta la eternidad. La vida de una API no funciona así, publicas una versión de tu API y ya sea para corregir bugs o para agregar nuevas funcionalidades te ves volviendo una y otra vez al lugar del crimen :)

Todas estas modificaciones si no tienes precaución te pueden llevar de cabeza al infierno de las dependencias (dependency hell), es decir, tu nueva API al no tener un sistema de denominación de versiones coherente e integrado no deja claro que las novedades dejan inservibles funcionalidades anteriores.

En un mundo como el actual, donde casi nadie desarrolla software desde cero -todos utilizamos y reutilizamos librerías de terceros- si vuestra API es muy utilizada imaginaos el efecto contagio que puede tener.

Hace falta por lo tanto un sistema de denominación de versiones coherente para permitir sacar muchas versiones de un software sin volvernos locos, versiones que deben ser informadas de manera automática desde el propio código. De esta manera todo el software de terceros que tenga dependencia del nuestro sabrá como orientarse para seguir funcionando sin problemas a la espera de hacer los cambios necesarios para funcionar con él.

Este sistema debe evitar demasiada rigidez que impida subir de versión y demasiada laxitud para evitar que saquemos demasiadas versiones (version promiscuity).

SemVer 2.0 define un estándar para denominar las versiones, este estándar sigue la estela de las normas habituales en el open source, X.Y.Z, versión mayor, versión menor, parches.

Los parches incrementan el contador de parches (Z), las evoluciones que no generen incompatibilidad la versión menor (Y) y las evoluciones que generen incompatibilidad la versión mayor (X).

Este sistema se denomina "Semantic versioning" y sirve para que cuando consultemos el número de versión sepamos si hay cambios y el nivel de esos cambios.

Este estándar tiene 11 sencillas reglas, podéis verlas en este enlace.

Todas son importantes, destacar que la API debe tener la información de la versión de manera pública, que no debe haber números que empiecen por 0 (menos el 0), que no se pueden cambiar los contenidos de una versión una vez se ha publicado. que la primera versión pública es siempre la 1.0.0. etc. Las tenéis en el enlace (en inglés) y están explicadas de manera muy clara y concisa.

Aquí os pongo una calculadora de versiones que te hace todavía la vida más fácil.

Espero que os sea de utilidad ^_^.