Explora el versionado semántico

  • 4 minutos

Una de las formas predominantes de control de versiones es el uso del control de versiones semántico (SemVer).

El control de versiones semánticos no es un estándar, pero ofrece una manera coherente de expresar la intención y la semántica de una versión determinada.

Describe una versión con respecto a su compatibilidad con versiones anteriores.

Formato de versionado semántico

El control de versiones semántico usa un número de versión de tres partes y una etiqueta opcional.

Formato Principal.Secundaria.Revisión

La versión tiene la forma de Major.Minor.Patch , que corresponde a los tres tipos de cambios descritos en la sección anterior.

Estructura de versión:

  • Principal: el primer número indica cambios importantes.
  • Menor: El segundo número indica nuevas características (compatibles con versiones anteriores).
  • Parche: Tercer número, indica correcciones de errores (compatibles con versiones anteriores).

Ejemplos de versiones que usan el esquema de control de versiones semántico:

  • 1.0.0 - Versión estable inicial
  • 3.7.129 - Versión 3 con muchas actualizaciones secundarias y de revisión
  • 2.0.0: versión principal 2 con cambios importantes

Estas versiones no tienen ninguna etiqueta.

Reglas de incremento de versión

Cuándo incrementar cada número:

Incrementar principal (X.0.0)

  • Cambios rupturistas: Cambios incompatibles en la API.
  • Quitar funcionalidad: Elimine las características en desuso.
  • Cambios arquitectónicos: Rediseño fundamental.

Example:

  • 1.5.3 → 2.0.0 cuando se introducen cambios rupturistas

Incrementar secundaria (x.Y.0)

  • Nuevas características: Agregue funcionalidad de forma compatible con versiones anteriores.
  • Desuso de la funcionalidad: Marcar las características como en desuso (pero aún funcionales).
  • Mejoras: Mejoras sustanciales en las características existentes.

Example:

  • 1.5.3 → 1.6.0 al agregar nuevas características

Incrementar revisión (x.y.Z)

  • Correcciones: Realice correcciones de errores compatibles con versiones anteriores.
  • Revisiones de seguridad: Corrija las vulnerabilidades de seguridad.
  • Mejoras de rendimiento: Optimizaciones de rendimiento menores.

Example:

  • 1.5.3 1.5.4→ para correcciones de errores

Versiones preliminares

En el caso de las versiones preliminares, es habitual usar una etiqueta después del número de versión normal.

Formato de etiqueta

Una etiqueta es un sufijo textual separado por un guión del resto del número de versión.

La propia etiqueta puede ser cualquier texto que describa la naturaleza de la versión preliminar.

Estructura de etiquetas:

Major.Minor.Patch-label

Etiquetas de versión preliminar comunes

Algunos ejemplos de estos son rc1, beta27y alpha, formando números de versión como:

  • 1.0.0-alpha - Versión de desarrollo temprana, inestable.
  • 1.0.0-beta - Función completa, pero potencialmente defectuosa.
  • 1.0.0-beta.2 - Segunda versión beta.
  • 1.0.0-rc1 - Versión candidata, potencialmente lista para su lanzamiento.
  • 1.0.0-preview - Versión preliminar de los comentarios anticipados.

Ejemplo de progresión de versiones:

1.0.0-alpha.1
1.0.0-alpha.2
1.0.0-beta.1
1.0.0-beta.2
1.0.0-rc1
1.0.0-rc2
1.0.0

Convenciones de etiquetas de versión preliminar

Prefijos de etiqueta comunes:

  • alfa: Versión muy temprana, espera errores y cambios importantes.
  • Beta: Característica completa, en pruebas.
  • rc (Versión candidata para lanzamiento): Versión potencialmente final, última fase de prueba.
  • Vista previa: Versión preliminar anticipada de los comentarios.
  • Dev: Instantánea de desarrollo.

Sufijos numéricos:

Las etiquetas suelen incluir números para versiones preliminares secuenciales:

  • 1.0.0-beta.1 1.0.0-beta.2 → →1.0.0-beta.3

Utilización de versiones preliminares

Las versiones preliminares son una manera común de prepararse para la versión de la versión sin etiqueta del paquete.

Ventajas de las versiones preliminares

Comentarios anticipados:

Los usuarios pioneros pueden depender de una versión preliminar para compilar con el nuevo paquete.

  • Integración de pruebas: Valide que el paquete funciona con sistemas existentes.
  • Notificar problemas: Busque errores antes del lanzamiento oficial.
  • Proporcione comentarios: Sugerir mejoras o cambios.

Lanzamiento gradual:

  • Lanzamiento escalonado: Liberar primero a un público pequeño.
  • Mitigación de riesgos: Detectar problemas antes de una versión amplia.
  • Creación de confianza: Cree confianza en la estabilidad.

Advertencias de versión preliminar

Por lo general, el uso de una versión preliminar de paquetes y sus componentes para el software publicado no es una buena idea.

Riesgos de usar versiones preliminares en producción:

  • Inestabilidad: Las versiones preliminares pueden tener errores no detectados.
  • Cambios importantes: Las versiones preliminares futuras pueden introducir cambios importantes.
  • Sin garantías: No hay garantías de compatibilidad con versiones anteriores.
  • Limitaciones de soporte técnico: Se ha limitado o no se admiten versiones preliminares.

Pruebas de versiones preliminares

Es bueno esperar el impacto de los nuevos componentes mediante la creación de una rama independiente en el código base y el uso de la versión preliminar del paquete.

Procedimientos recomendados para probar versiones preliminares:

  • Rama independiente: Cree una rama de características para las pruebas.
  • Entorno aislado: Prueba en entornos que no son de producción.
  • Comportamiento de supervisión: Observe si hay problemas inesperados de comportamiento o rendimiento.
  • Problemas del documento: Realice un seguimiento de los problemas encontrados.

Es probable que haya cambios incompatibles de una versión preliminar a la versión final.

Metadatos e información de compilación

SemVer 2.0 también admite metadatos de compilación anexados con un signo más:

1.0.0-beta.1+20231015.abc123

Metadatos de compilación:

  • No se tiene en cuenta en la precedencia de la versión: Dos versiones diferentes solo en los metadatos de compilación se consideran iguales.
  • Propósitos de información: resulta útil para realizar el seguimiento de números de compilación, hashes de confirmación.
  • Ejemplo:1.0.0+build.123 o 1.0.0-beta+exp.sha.5114f85

Precedencia de versión

SemVer define reglas claras para la precedencia de versión:

Reglas de comparación

  1. Comparar principal, secundaria, revisión: en ese orden de manera numérica.
  2. Versiones preliminares: Siempre tiene una prioridad menor que la versión normal asociada.
  3. Comparación de etiquetas: Segmentos alfanuméricos comparados léxicamente, segmentos numéricos comparados numéricamente.

Ejemplos en orden (más bajo a más alto):

1.0.0-alpha
1.0.0-alpha.1
1.0.0-alpha.beta
1.0.0-beta
1.0.0-beta.2
1.0.0-beta.11
1.0.0-rc.1
1.0.0
1.0.1
1.1.0
2.0.0

Ventajas del versionado semántico

Comunicación clara:

  • Intento: El número de versión comunica claramente la naturaleza de los cambios.
  • Compatibilidad: Fácil de determinar si la actualización es segura.
  • Previsibilidad: Control de versiones coherente entre paquetes.

Administración automatizada de dependencias:

  • Restricciones de versión: Los administradores de paquetes pueden resolver las versiones automáticamente.
  • Actualizaciones seguras: Las herramientas pueden actualizarse de forma segura a versiones compatibles.
  • Resolución de conflictos: Más fácil de resolver conflictos de dependencias.

Adopción del ecosistema:

  • Estándar del sector: Ampliamente adoptado en muchos ecosistemas.
  • Compatibilidad con herramientas: Los administradores de paquetes comprenden SemVer.
  • Expectativas de la comunidad: Los desarrolladores esperan el cumplimiento de SemVer.

Versionado semántico en Azure Artifacts

Azure Artifacts admite el control de versiones semánticos en todos los tipos de paquetes:

  • NuGet: Compatibilidad con SemVer 2.0 nativo.
  • npm: SemVer es el estándar.
  • Maven: Compatible con los principios de SemVer.
  • Python: PEP 440 es compatible con conceptos de SemVer.
  • Paquetes universales: Usa SemVer 2.0.

Vistas de fuente y Versionamiento Semántico:

  • @Vista de pre-lanzamiento: Incluye automáticamente versiones con etiquetas.
  • @Vista de lanzamiento: Solo incluye versiones sin etiquetas.
  • @Vista local: Muestra todas las versiones independientemente de la etiqueta.

Implementación de versionado semántico

Control de versiones manual:

  • Actualizar archivos de paquete: Actualizar manualmente la versión en package.json, .nuspec, etc.
  • Confirmar con la etiqueta : confirmación de la etiqueta con el número de versión.

Control de versiones automatizado:

# Using npm version command
npm version patch  # Increment patch: 1.0.0 -> 1.0.1
npm version minor  # Increment minor: 1.0.1 -> 1.1.0
npm version major  # Increment major: 1.1.0 -> 2.0.0

# With prerelease
npm version prerelease --preid=beta  # 1.0.0 -> 1.0.1-beta.0

En canalizaciones de CI/CD:

# Azure Pipelines example
- task: GitVersion@5
  inputs:
    runtime: "core"
    configFilePath: "GitVersion.yml"

- script: |
    echo "Semantic Version: $(GitVersion.SemVer)"
    echo "NuGet Version: $(GitVersion.NuGetVersion)"
  displayName: "Display version"

Consulta también Versionamiento semántico 2.0.0.