¿Semantic Versioning permite 4 componentes en los números de versión?

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

5.0.1.2

¿El control de versiones semántico permite esto?

Y como pregunta secundaria de nivel superior y más discutible, ¿realmente importa? Empecé a pensar que podría ser una buena idea aplicar versiones semánticas, pero en última instancia, entidades como PCI lo anulan.

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

versioning semantic-versioning pci

— void.pointer
fuente

El control de versiones semántico es una guía. ¿De dónde viene PCI estado nada acerca de cómo son las cosas esté versionado?

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

— void.pointer 01 de

@ void.pointer ¿puede dar un ejemplo de por qué está usando el cuarto componente? ¿Lo está utilizando para omitir básicamente los costos internos y las estructuras contables, lo que le permite a su equipo rastrear nuevas características sin aumentar los números de parches?

— enderland 01 de

@enderland Sí, básicamente. MAJOR(PCI).MINOR(PCI).FEATURE.HOTFIX+BUILD. Básicamente, solo se nos permite cambiar el tercer y cuarto componente sin involucrar a PCI (y posteriormente a los señores de PCI en la empresa). Para mí, parece 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.

— void.pointer

También usamos 4 grupos, y no 3. ¿Por qué? Porque C ++. C ++ tiene compatibilidad binaria hacia atrás y compatibilidad hacia atrás de origen : la primera implica la segunda, pero la relación no es simétrica. Por lo tanto, utilizamos el cuarto grupo para compatibilidad binaria (puede parchear en caliente el sistema) y el tercero para compatibilidad de fuente (necesita volver a compilar, pero no debería tener que modificar su propio código). Y sabes qué, ¡funciona para nosotros!

— Matthieu M.

Respuestas:

Parece que está pasando por alto las convenciones normales solo para evitar la sobrecarga / auditorías del proceso. Eso ... me parece preocupante.

Lo que está haciendo es efectivamente hacer un número de versión adicional (su dígito PCI menor) de manera algo intencional para mover sus funciones / números de versión menores de vuelta a un lugar, para que ya no activen sus criterios de auditoría interna.

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

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

Versión PRINCIPAL cuando realiza cambios de API incompatibles,

Versión MENOR cuando agrega funcionalidad de una manera compatible con versiones anteriores, y

Versión PATCH cuando realiza correcciones de errores compatibles con versiones anteriores.

Las etiquetas adicionales para metadatos previos al lanzamiento y de compilación están disponibles como extensiones del formato MAJOR.MINOR.PATCH .

El énfasis es mío.

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

En caso afirmativo, las especificaciones de versiones semánticas lo permiten. Si "no", técnicamente no está siguiendo las versiones semánticas.

Y como pregunta secundaria de nivel superior y más discutible, ¿realmente importa?

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

Las correcciones de errores que no afectan la API incrementan la versión del parche, las adiciones / cambios de API compatibles con versiones anteriores incrementan la versión menor, y los cambios de API incompatibles con versiones anteriores aumentan 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 significado sobre el código subyacente y lo que se ha modificado de una versión a la siguiente.

Es un sistema que ayuda a aclarar más cuando el control de versiones afecta a los usuarios intermedios de la API.

Mientras su API sea igualmente clara, no es un gran problema la forma en que elija. Las versiones semánticas resultan ser 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 radical.

Todo eso es parte de lo que significan los números de versión.

@enderland Sí, básicamente. MAYOR (PCI) .MINOR (PCI). CARACTERÍSTICA. CORREGIR + CONSTRUIR. Básicamente, solo se nos permite cambiar el tercer y cuarto componente sin involucrar a PCI (y posteriormente a los señores de PCI en la compañía). Para mí, parece 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, esta bien Tiene un sistema que funciona para usted y satisface sus necesidades. Ese es el punto de versionar.

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

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

— Enderland
fuente

Con respecto a su edición en la parte superior: Déjame jugar al abogado del diablo aquí. Las auditorías de PCI le cuestan dinero a la empresa, y no todas las funciones implementadas son de su interés. Entonces, ¿por qué incurrir en costos y otros gastos generales solo en los principios? ¿Cómo es esto tan preocupante? Me doy cuenta de que el método para determinar las auditorías probablemente sea defectuoso, pero la separación de las preocupaciones parece razonable. Las cosas que no están relacionadas remotamente con el procesamiento de la tarjeta son irrelevantes para PCI.

— void.pointer

@ void.pointer No estoy en condiciones de juzgar por qué / cómo se determinan sus auditorías. Pero alguien decidió que quería auditar basándose en criterios específicos. Pasar intencionalmente ese criterio de auditoría parece preocupante (independientemente de cuánto dinero ahorre al hacerlo).

— enderland 01 de

@ void.pointer, enderland tiene razón. Si un terrorista amenaza con matar a su familia si sus versiones no están compuestas completamente por letras alfabéticas, el verdadero problema es el terrorista. Siéntase libre de no seguir las versiones semánticas para evitarlo (de hecho, lo recomendaría encarecidamente en este caso), pero realmente es eso: una solución necesaria por un problema diferente.

— Paul Draper

@PaulDraper ¿Cuándo se convirtió semver en la versión One True Way to version?

— Andy

@ Andy, no fue así. El OP preguntó por SemVer. IDK por qué, pero eso fue lo que hizo.

— Paul Draper

En la versión actual de Semantic Versioning, que es 2.0.0 , no. Hay un requisito que define la versión como la forma XYZ donde X, Y y Z son enteros no negativos que no contienen ceros a la izquierda:

Un número de versión normal DEBE tomar la forma XYZ donde X, Y y Z son enteros no negativos, y NO DEBE contener ceros a la izquierda. X es la versión principal, Y es la versión secundaria y Z es la versión del 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 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.

Sin embargo, algo importante a tener en cuenta es que el control de versiones semántico es específicamente para el software que declara una API pública:

El software que utiliza versiones semánticas 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 lo que significan los números de versión, tanto para uso interno como externo. Las versiones son solo identificadores que le permiten hablar sobre las diferencias en el software en dos momentos diferentes. El control de versiones semántico es un método para poner reglas a este respecto, por lo que si sabe que una aplicación está usando el control de versiones semántico, 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 alguna razón, documentar las reglas para sus usuarios también debería ser suficiente.

— Thomas Owens
fuente

+1 para la nota API pública. No tenemos una API pública, pero tenemos la capacidad de romper la compatibilidad con versiones anteriores en otros aspectos, como los datos. Es posible que enviemos una compilación que se instala en versiones anteriores, pero los datos no cambian, y ya no podemos leer esos datos (aunque

— generalmente admitimos los