¿Por qué build.number es un "abuso" de las versiones semánticas?

Estaba explicando un sistema de construcción propuesto (Gradle / Artifactory / Jenkins / Chef) a uno de nuestros arquitectos principales, y él me hizo un comentario con el que estoy en desacuerdo, pero no tengo la experiencia suficiente para considerarlo.

Este proyecto construye una biblioteca Java (JAR) como un artefacto para ser reutilizado por otros equipos. Para el control de versiones, me gustaría utilizar el enfoque semántico de:

<major>.<minor>.<patch>

Donde patchindica correcciones de errores / emergencias, minorindica versiones compatibles con versiones anteriores e majorindica refactorizaciones masivas de la API y / o cambios incompatibles con versiones anteriores.

En cuanto a la entrega, aquí es lo que quiero: un desarrollador confirma algo de código; Esto desencadena una compilación en un entorno QA / TEST. Se ejecutan algunas pruebas (algunas automatizadas, algunas manuales). Si todas las pruebas pasan, entonces una versión de producción publica el JAR en nuestro repositorio interno. En este punto, el JAR debería tener una versión adecuada, y mi intención era utilizar el build.numberque se genera y proporciona automáticamente nuestra herramienta de CI para actuar como el número de parche.

Por lo tanto, el versionado en realidad sería:

<major>.<minor>.<build.number>

Una vez más, dónde build.numberlo proporciona la herramienta CI.

El arquitecto descartó esto, diciendo que usar el número de compilación de CI era un "abuso" de las versiones semánticas.

Mi pregunta es: ¿es correcto? Y si es así, ¿por qué? Y si no, ¿Pórque no?

continuous-integration versioning builds continuous-delivery semantic-versioning herpylderp
fuente

Respuestas:

Su número de compilación no se restablecerá a 0, cuando las versiones menores y mayores aumentan, esto viola las secciones 7 y 8 de las especificaciones :

La versión menor Y (xYz | x> 0) DEBE incrementarse si se introduce una nueva funcionalidad compatible con versiones anteriores en la API pública. DEBE incrementarse si alguna funcionalidad de API pública está marcada como obsoleta. PUEDE incrementarse si se introducen nuevas funcionalidades sustanciales o mejoras dentro del código privado. PUEDE incluir cambios en el nivel del parche. La versión del parche DEBE restablecerse a 0 cuando se incrementa la versión menor.

La versión principal X (Xyz | X> 0) DEBE incrementarse si se introducen cambios incompatibles con versiones anteriores en la API pública. PUEDE incluir cambios menores y de nivel de parche. El parche y la versión menor DEBEN restablecerse a 0 cuando se incrementa la versión principal.

Por lo tanto, los números de versión (mayor, menor, parche) deben proporcionarse manualmente, ya que se usan para informar a los usuarios sobre los cambios en un lugar sin que tengan que mirar su registro de cambios u otro documento.

Si desea incluir su número de compilación, puede agregarlos después de un +(sección 10):

Los metadatos de la compilación PUEDEN denotarse agregando un signo más y una serie de identificadores separados por puntos inmediatamente después del parche o la versión preliminar. Los identificadores DEBEN comprender solo caracteres alfanuméricos y guiones ASCII [0-9A-Za-z-]. Los identificadores NO DEBEN estar vacíos. Los metadatos de compilación DEBEN ignorarse al determinar la precedencia de la versión. Por lo tanto, dos versiones que difieren solo en los metadatos de compilación tienen la misma prioridad. Ejemplos: 1.0.0-alpha + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp.sha.5114f85.

Residuo
fuente

Seguimiento rápido @Residuum (y BTW +1 para la respuesta): ¿los números de versión siempre deben derivarse manualmente? Si no es así, ¿qué herramientas podrían usarse en lugar del número de CI / build?

herpylderp

@herpylderp en absoluto, la 'especificación' de Tom Preston-Werner es solo su opinión, muchas otras compañías tienen estándares diferentes (generalmente muy similares entre sí). En la mayoría de ellos, un número generado automáticamente es parte de la versión. Usar el número de compilación de CI es algo sensato.

gbjbaanb

Aún puede usar la herramienta CI, si la herramienta le permite hacer aritmética en números de compilación. Cualquiera sea la compilación que publique como actualización de versión principal o secundaria, conecte ese número de compilación a una expresión para la cadena de versión que resta del número de compilación de CI actual. Voila, acaba de restablecer su número de compilación a cero para la nueva versión, sin realmente restablecer su número de compilación.

KeithS

En cuanto a mí, solo uso [major]. [Minor]. [Revision]. [SVN-Version] para DLL y [major]. [Minor]. [SVN-Version] para los instaladores. El número de compilación de CI es solo para uso interno, para mostrar dónde se pudo volver a ejecutar una compilación que falló exactamente en la misma base de código después de un cambio en el entorno de CI (instalar un certificado clave, agregar bibliotecas comunes al GAC, etc.).

KeithS

@gbjbaanb et al .: En cada discusión sobre "versiones semánticas" de la que formé parte, la definición de semver.org fue el tema. Busque en la web "versiones semánticas", y al menos la primera página presenta pros / contras sobre la definición de semver.org . Usted es libre de usar sus propios esquemas de versiones, pero no lo llame versión semántica, ya que este término está claramente definido.

Residuo

Una razón es que el parche puede requerir varias compilaciones, por lo que si tiene la versión 5.7 y desea parchearlo a 5.7.1, pero sus primeras 2 correcciones de errores no se compilan cuando se envían al sistema CI, entonces será a 5.7.3 antes de lanzar su primer parche!

La respuesta es simplemente usar 4 dígitos (como suelen tener los sistemas de Microsoft). El cuarto es un número de compilación y se usa "solo para información". En general, las personas ponen el número de versión del repositorio allí (si usan SVN o TFS o similar), lo cual es realmente bueno, ya que puede verificar qué confirmación exacta se usó para construir los binarios. Si no tiene tal cosa, entonces el número de compilación de CI es una aproximación razonable (ya que esperaría que su sistema de CI pueda recordar los números de compilación y vincularlo al historial de repositorios, pero no depende del CI sistema recordándolos: nunca puede eliminar compilaciones antiguas).

Una cosa a tener en cuenta, el esquema de Microsoft para el control de versiones utiliza la tercera posición para los números de compilación. Chrome usa solo 1 número. Ubuntu usa la fecha. No hay un "estándar" para usar , excepto que todos los números deben incrementarse.

gbjbaanb
fuente

Aunque no existe un estándar que se use o aplique universalmente, la pregunta parece ser específicamente sobre el control de versiones semántico que tiene una especificación.

Doval

Incluso eso se rompe en el campo, por ejemplo, el control de versiones NuGet de Microsoft usa semver, de manera interrumpida (usando el estilo de prelanzamiento para los números de compilación), y Ruby usa major.minor.teeny.patch . De todos modos, dado que el número de compilación puede ser parte de la semver, el arquitecto estaba hablando (aunque es cierto que debería ser + build, no en la tercera posición).

gbjbaanb

La especificación SemVer 2.0 es de 2013 y la especificación 1.0 es de 2012 por lo que puedo decir. Es probable que NuGet y Ruby estuvieran haciendo lo suyo antes de que apareciera la especificación. No es que la especificación de SemVer sea nueva; solo formaliza lo que la gente ya ha estado haciendo para que todos podamos finalmente acordar una forma de hacerlo en lugar de una docena de variaciones.

Doval

"tiene la versión 5.7 y desea parchearla en 5.7.1, pero sus primeras 2 correcciones de errores no se compilan cuando se envían al sistema de CI, entonces estará en 5.7.3 antes de lanzar su primer parche ! " ok, pero que? No recuerdo nada en semver que diga que los números no deben saltarse.

Andy