¿Qué esquema de numeración de versión usar?

Estoy buscando un esquema de numeración de versiones que exprese la extensión del cambio, especialmente la compatibilidad.¿Qué esquema de numeración de versión usar?

Apache APR, por ejemplo, utilizar el esquema de numeración versión bien conocida

<major>.<minor>.<patch> 
example: 4.5.11

Maven sugiere una similar pero más detallada del esquema:

<major>.<minor>.<patch>-<qualifier>-<build number> 
example: 4.5.11-RC1-3732

donde se define el esquema de versiones Maven? ¿Hay convenciones para el calificador y el número de compilación? Probablemente es una mala idea usar maven pero no seguir el esquema de versión de Maven ...

¿Qué otros esquemas de numeración de versiones conoce usted? ¿Qué esquema preferirías y por qué?

Fuente

2010-01-12 deamon

¿Ayudaría http://stackoverflow.com/questions/1889615/version-numbering-basics? – VonC

Aquí está el current Maven version comparison algorithm, y un discussion de él. Siempre que las versiones solo crezcan y todos los campos, excepto el número de compilación, se actualicen manualmente, estará bien. Los calificadores funcionan así: si uno es un prefijo del otro, más tiempo es más antiguo. De lo contrario, se comparan alfabéticamente. Úselos para pre-lanzamientos.

Secundando el uso de versiones semánticas para expresar compatibilidad; major es para cambios no compatibles con versiones anteriores, menores para características compatibles con versiones anteriores, parches para correcciones de errores compatibles con versiones anteriores. Documentarlo para que los usuarios de su biblioteca puedan expresar dependencias en su biblioteca correctamente. Sus instantáneas son automáticas y no tienen que incrementarlas, excepto la primera instantánea después de una publicación debido a la forma en que se comparan los prefijos.

Fuente

2010-01-12 11:27:55 Tobu

Recomendaría el estándar de versión semántica, que también parece seguir el sistema de versiones de Maven. Por favor, echa un vistazo,

http://semver.org/

En resumen, es <major>.<minor>.<patch><anything_else>, y se puede añadir reglas adicionales a la parte else nada como parece en condiciones de ti. p.ej. -<qualifier>-<build_number>.

Fuente

2010-01-12 11:37:37 sixohsix

El esquema - - de Maven parece no coincidir exactamente con la recomendación de semver.org. semver.org: "Un número de versión especial PUEDE denotarse al agregar una cadena arbitraria ** inmediatamente después de ** la versión del parche. La cadena DEBE estar compuesta únicamente por caracteres alfanuméricos más guiones [0-9A-Za-z-] y ** DEBE comenzar con un carácter alfabético [A-Za-z] **. " – deamon

@deamon semver.org probablemente lo cambió hace años pero, para el registro, ahora cumple con el esquema maven: "Una versión preliminar se PUEDE denotar agregando un guión y una serie de identificadores separados por puntos inmediatamente después de la versión del parche. DEBE comprender solo caracteres alfanuméricos ASCII y guiones [0-9A-Za-z-]. Los identificadores NO DEBEN estar vacíos. Los identificadores numéricos NO DEBEN incluir ceros a la izquierda. " – Kapep

@kapep: Los formatos aún no son totalmente compatibles, porque el algoritmo de comparación de Sever es mucho más complicado que lo que utiliza Maven. Pero si te limitas a "-RC1", "-RC2" o similar, deberías estar bien. – sleske

Después de leer un montón de artículos/QA/Preguntas frecuentes/libros me vuelvo a pensar que [MAYOR]. [MINOR]. [REV] es el esquema de versiones más útil para describir la compatibilidad entre la versión del proyecto (esquema de versiones para desarrollador, no para marketing).

PRINCIPALES cambios es hacia atrás incompatibles y requieren cambiar nombre del proyecto, ruta de los archivos, GUID, etc.

MINOR cambios es compatible con versiones anteriores. Marque la introducción de las nuevas características .

REV para la seguridad/corrección de errores. Adelante hacia adelante y hacia atrás.

Este esquema de versiones inspirado por libtool la semántica de versiones y por los artículos:

http://www106.pair.com/rhp/parallel.html

NOTA: También recomiendo proporcionar acumulación/fecha/custom/calidad información como adicionales (Build número, fecha de compilación, nombre del cliente, calidad de lanzamiento):

Hola aplicación v2.6.34 para Banco Nacional, 2011-05-03, beta, construir

Pero esta información es no versiones de información!

Fuente

2011-10-11 18:24:00 gavenkoa

Puramente para completar, mencionaré el old Apple standard for version numbers. Esto se ve como versión principal. versión secundaria. error versión. etapa. revisión sin liberación. Etapa es un código elaborado a partir del conjunto d (desarrollo), a (alfa), b (beta), o fc (nave cliente final - más o menos el mismo que el candidato de versión, creo) .

La revisión de etapa y sin liberación solo se usa para versiones que no sean las adecuadas.

Entonces, la primera versión de algo podría ser 1.0.0. Es posible que haya lanzado una corrección de errores como 1.0.1, una nueva versión (con más funciones) como 1.1 y una reescritura o actualización mayor como 2.0. Si luego desea trabajar para 2.0.1, puede comenzar con 2.0.1d1, 2.0.1d2, a 2.0.1d153 o lo que sea que le tomó, luego envíe 2.0.1a1 a QA, y después de que hayan aprobado 2.0.1a37 , envíe 2.0.1b1 a algunos apostadores dispuestos, luego de que 2.0.1b9 haya sobrevivido una semana en el campo, queme 2.0.1fc1 y comience a obtener firmas. Cuando 2.0.1fc17 tenga suficiente, se convertiría en 2.0.1, y habría mucho regocijo.

Este formato se estandarizó lo suficiente como para que hubiera un formato binario empaquetado para él y rutinas auxiliares en las bibliotecas para hacer comparaciones.

Fuente

2012-04-27 16:09:34

Puramente por completitud (:-)), me gustaría señalar que en mi humilde opinión, la necesidad de construir por separado para cada etapa (que este esquema implica) no es una buena idea. Al menos las construcciones para el control de calidad/pruebas finales deberían funcionar sin cambios en la producción. Cualquier diferencia requerida en el comportamiento debe inyectarse a través de la configuración. Ver p. [¿Separaciones separadas de "depuración" y "liberación"?] (Http://stackoverflow.com/questions/420343/separate-debug-and-release-builds). – sleske

@sleske No creo que implique compilaciones separadas para cada etapa. Si se encuentra en la fase de prueba beta, debería crear 1.2.3b4 en dev, ponerlo a través de CI, obtener control de calidad para aprobarlo, hacer UAT, luego extenderlo a beta-testers, utilizando el mismo binario en todo momento. Más bien, lo que implica es que en cualquier punto, usted sabe hasta dónde puede llegar una compilación, para que sepa cuándo se compromete que solo se usará en desarrollo, se enviará a probadores beta, se liberará, etc. Hay alguna duplicación en las transiciones. , por ejemplo, si 1.2.3b10 pasa la prueba beta, el mismo código probablemente se convertirá en 1.2.3fc1, lo que no es ideal. –

Tenga en cuenta que un esquema de número de versión (como x.y.0 frente a x.y) puede estar limitado por factores externos.

Considere que announcement for Git 1.9 (Januaury 2014):

Una versión candidata Git v1.9-RC2 ya está disponible para las pruebas en los lugares habituales.

He oído rumores de que varias herramientas de terceros no les gustan los números de versión de dos dígitos (por ejemplo, "Git 2.0") y empezó a vomitar izquierda y derecha cuando los usuarios instalan v1.9-RC1 .
Si bien es tentador reírse de ellos por su suposición descuidada, también soy práctico y no me importa llamar al próximo lanzamiento v1.9.0 para ayudarlos.

Si vamos por ese camino (y me inclino a ir por ese camino en este momento), el esquema de versiones será:

La próxima versión candidata habrá v1.9.0-rc3, no v1.9-rc3;

La primera versión de mantenimiento para v1.9.0 será v1.9.1 (y la primera será v1.9.N); y

La versión de la función después de v1.9.0 será v1.10.0 o v2.0.0, dependiendo de cuán grande sea el salto de función que estamos viendo.

Fuente

2014-02-04 07:30:33 VonC

¿Qué esquema de numeración de versión usar?

Respuesta

Cuestiones relacionadas