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.