Versionado de artefactos de software en GLA

Semantic Versioning

En GLA se usará la política de versionado definida en SemVer para versionar los artefactos de software incluyendo aplicaciones, APIs y librerías. De esa especificación subrrayamos los siguientes puntos: Un número de versión debe tomar la forma X.Y.Z, donde X, Y y Z son números enteros positivos sin ceros a la izquierda. X es la versión mayor, Y la versión menor y Z el hot-fix (o patch). Cada elemento se debe incrementar numéricamente; es decir, 1.9.0 pasa a 1.10.0 que pasa a 1.10.1. Una vez que un artefacto versionado se libera, el contenido de dicho paquete NO SE PUEDE modificar. Cada modificación DEBE liberarse como una versión nueva. Se pueden expresar versiones pre-release agregando un guion y una serie de identificadores separados por puntos inmediatamente después del número de hot-fix (Z). Por ejemplo, 2.1.0-alpha1.

Cuándo cambiar el número de versión.

El componente X o mayor del número de versión debe incrementarse cuando los cambios incluyen incompatibilidades con versiones anteriores en la interfaz pública del artefacto. El componente Y y el Z se incrementan cuando los cambios mantienen la compatibilidad para atrás.
El cambio del número de versión está íntimamente relacionado con las ramas de desarrollo de GitFlow. El componente X e Y siempre hacen referencia a cambios que parten de la rama develop y el componente Z (hot-fix) aquellos cambios que se inician en la rama hot-fix y se aplican directo en producción. Es decir, un hot-fix debe si o si incrementar el componente Z del número de versión. Siempre que el componente Y se incrementa el Z vuelve a cero, de la misma forma cada vez que se incrementa el componente X el que vuelve a cero ese el Y y por ende el Z.

¿Qué artefactos específicamente se incluyen?

Los artefactos a los que obligatoriamente hace referencia esta especificación son los siguientes:

• APIs públicas y privadas. Las APIs tienen la ventaja de poder seguir ofreciendo versiones anteriores en otros paths. Por ejemplo: /v1/api/oredenesDeEnvio y /v2/api/ordenesDeEnvio. En este caso v1 y v2 deben indicar el componente X del número de versión ya que es el que indica incompatibilidades entre versiones.

• Interfaces UX
  TBA

• Librerías Aquellas que se suban a NuGet obligatoriamente.

• Aplicaciones que ejecutan en application servers (PHP, ASP.NET) Como PFS o Calidad Certificada.

• Esquemas de datos Como el catálogo de eventos.

En general todo artefacto que se vea afectado por un flujo de desarrollo como GitFlow es plausible de versionarse según esta especificación.