¿El Versing semántico permite 4 componentes en los números de versión?

14

Todos los ejemplos de versiones semánticas que he visto muestran 3 componentes en uso. No más de 2 personajes del periodo. En $DAYJOB , usamos 4 componentes en nuestros números de versión:

5.0.1.2

¿Permiten esto las versiones semánticas?

Y como una pregunta lateral de más alto nivel y más discutible, ¿realmente importa? Empecé a pensar que podría ser una buena idea imponer el control de versiones semántico, pero en última instancia las entidades como PCI lo anulan.

Debería haber aclarado sobre mi comentario de PCI. El problema es que las auditorías y su costo influyen cuando los componentes mayor y menor cambian, no necesariamente una característica realmente nueva. Por ejemplo, si se introduce una característica relacionada con los pagos, saltamos el número menor para PCI. Pero si agregamos una nueva característica relacionada con algo en la interfaz gráfica de usuario, no es así. Solo el parche cambia. Entonces, en este caso, realmente no podemos opinar sobre el tema como desarrolladores, ya que alguien más toma esas decisiones.

    
pregunta void.pointer 01.10.2015 - 15:06

2 respuestas

20

Suena como si estuvieras evitando las convenciones normales solo para evitar la sobrecarga / auditorías del proceso. Eso ... me parece preocupante.

Lo que está haciendo es hacer que un número de versión adicional (su dígito PCI menor) sea un tanto intencional para mover sus números de versión / versión menor atrás a un lugar, para que ya no se active su auditoría interna criterios.

De todos modos, respondiendo a su pregunta sobre el control de versiones semántico, la especificación para el control de versiones semántico dice:

  

Dado un número de versión MAJOR.MINOR.PATCH, incremente el:

     
  • Versión PRINCIPAL cuando realiza cambios en la API incompatibles,
  •   
  • versión MENOR cuando agrega funcionalidad de una manera compatible con versiones anteriores, y
  •   
  • Versión PATCH cuando hace correcciones de errores compatibles con versiones anteriores.
  •   
  • Las etiquetas adicionales para el lanzamiento previo y los metadatos de compilación están disponibles como extensiones del formato MAJOR.MINOR.PATCH .
  •   

Énfasis mío.

Entonces, la pregunta es, ¿estás usando el cuarto carácter para los metadatos de prelanzamiento / creación? ¿O es básicamente otra indicación de versión que está lanzando?

Si la respuesta es "sí", la especificación de la versión semántica lo permite. Si la respuesta es "no", técnicamente no está siguiendo las versiones semánticas.

  

Y como pregunta lateral de mayor nivel y más discutible, ¿realmente importa?

Si quiere seguirlo rígidamente o no, es una decisión que usted y su equipo deben tomar. El propósito del control de versiones semántico es ayudar con la compatibilidad de API:

  

Las correcciones de errores que no afectan a la API incrementan la versión del parche, las adiciones / cambios de API compatibles con versiones anteriores incrementan la versión secundaria, y los cambios de API incompatibles con versiones anteriores incrementan la versión principal.

     

Yo llamo a este sistema "Versiones semánticas". Bajo este esquema, los números de versión y la forma en que cambian transmiten un significado sobre el código subyacente y lo que se ha modificado de una versión a otra.

Es un sistema que ayuda a dejarlo más claro cuando las versiones afectan a los usuarios posteriores de la API.

Siempre que su API sea igualmente clara, no es un gran problema la forma que elija. Resulta que las versiones semánticas son sencillas, por ejemplo, si estoy usando 3.4.2 y necesito actualizar a 3.4.10 Sé que puedo hacerlo sin romper nada. Si la nueva versión es 3.5.1, sé que es compatible con versiones anteriores. Y sé que la versión 4.0.1 sería un cambio importante.

Eso es todo parte de lo que significan los números de versión.

  

@enderland Sí, básicamente. MAYOR (PCI) .MINOR (PCI) .FEATURE.HOTFIX + BUILD. Básicamente solo se nos permite cambiar el 3er y 4to componente sin involucrar a PCI (y posteriormente a los señores de PCI en la compañía) involucrados. Para mí, siento que esto es un poco artificial, no estoy seguro de que estén justificados en la forma en que administran el número de versión, pero no sé lo suficiente sobre PCI y el proceso de auditoría para decir lo contrario.

Ok, esto está bien. Usted tiene un sistema que funciona para usted y satisface sus necesidades. Ese es el punto de la versión.

Si su API es privada (solo está orientada internamente) realmente no importa cómo realice la versión, siempre y cuando tenga sentido para usted y para todos los que la usan. Donde importa la versión en un formato estándar es cuando tiene muchos otros consumidores de su API que necesitan saber "¿qué significa esta versión?"

Tener un sistema de versiones arbitrario confundirá a las personas que están acostumbradas a otros sistemas, como las versiones semánticas. Pero si nadie está realmente usando su sistema de control de versiones, excepto las personas que lo están creando, en realidad no importa.

    
respondido por el enderland 01.10.2015 - 15:26
8

En la versión actual de Versing semántico, que es 2.0.0 , no. Existe un requisito que define la versión como la forma X.Y.Z donde X, Y y Z son enteros no negativos que no contienen 0s iniciales:

  

Un número de versión normal DEBE tomar la forma X.Y.Z, donde X, Y y Z son enteros no negativos, y NO DEBEN contener ceros iniciales. X es la versión principal, Y es la versión secundaria y Z es la versión de parche. Cada elemento DEBE aumentar numéricamente. Por ejemplo: 1.9.0 - > 1.10.0 - > 1.11.0.

Sin embargo, la capacidad de agregar metadatos está permitida para:

  

Los metadatos de construcció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 incluir solo caracteres alfanuméricos ASCII y guión [0-9A-Za-z-]. Los identificadores NO DEBEN estar vacíos. Los metadatos de compilación DEBERÍAN ser ignorados 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.

Algo importante a tener en cuenta, sin embargo, es que las versiones semánticas son específicamente para software que declara una API pública:

  

El software que utiliza la versión semántica DEBE declarar una API pública. Esta API podría declararse en el código mismo o existir estrictamente en la documentación. Sin embargo, se hace, debe ser preciso y completo.

Esto tiende a apoyar el desarrollo de bibliotecas o servicios y no a nivel de aplicación.

Lo importante a considerar es el significado de sus números de versión, tanto para uso interno como externo. Las versiones son solo identificadores que le permiten hablar sobre las diferencias de software en dos momentos diferentes. La versión semántica es un método para poner reglas alrededor de esto, por lo que si sabe que una aplicación está utilizando la versión semántica, puede determinar más fácilmente el nivel de esfuerzo requerido para actualizar sus paquetes. Seguir un estándar común puede ser bueno, pero si no puede, por cualquier motivo, documentar las reglas para sus usuarios también debería ser suficiente.

    
respondido por el Thomas Owens 01.10.2015 - 15:35

Lea otras preguntas en las etiquetas