schema - sitio - ¿Qué esquema de numeración de versión usar?
no detectamos datos estructurados en tu sitio. (5)
Estoy buscando un esquema de numeración de versiones que exprese el alcance del cambio, especialmente la compatibilidad.
Apache APR , por ejemplo, utiliza el conocido esquema de numeración de versiones
<major>.<minor>.<patch>
example: 4.5.11
Maven sugiere un esquema similar pero más detallado:
<major>.<minor>.<patch>-<qualifier>-<build number>
example: 4.5.11-RC1-3732
¿Dónde se define el esquema de versionamiento de Maven? ¿Hay convenciones para el calificador y número de compilación? Probablemente sea una mala idea usar maven pero no seguir el esquema de la versión de Maven ...
¿Qué otros esquemas de numeración de versión sabes? ¿Qué esquema preferirías y por qué?
Aquí está el algoritmo actual de comparación de versiones de Maven , y una discussion de él. Siempre y cuando las versiones solo crezcan, y todos los campos, excepto el número de compilación, se actualicen manualmente, estarás bien. Los calificadores funcionan así: si uno es un prefijo del otro, más largo es más antiguo. De lo contrario se comparan alfabéticamente. Úsalos para pre-lanzamientos.
Secundando el uso de versiones semánticas para expresar compatibilidad; mayor es para cambios no compatibles con versiones anteriores, menor para características compatibles con versiones anteriores, parche para correcciones de errores compatibles con versiones anteriores. Documéntelo para que los usuarios de su biblioteca puedan expresar las dependencias en su biblioteca correctamente. Sus instantáneas están automatizadas y no tienen que incrementarlas, excepto la primera instantánea después de un lanzamiento debido a la forma en que se comparan los prefijos.
Después de leer muchos artículos / QAs / FAQs / libros, me vuelvo a pensar que [MAJOR]. [MINOR]. [REV] es el esquema de versión más útil para describir la compatibilidad entre la versión del proyecto (esquema de versión para desarrollador, no para marketing) .
Los cambios PRINCIPALES son incompatibles con versiones anteriores y requieren cambiar el nombre del proyecto, la ruta a los archivos, los GUID, etc.
Los cambios MENORES son compatibles con versiones anteriores. Marca introducción de nuevas características.
REV para la seguridad / correcciones de errores. Compatible con versiones anteriores y posteriores.
Este esquema de versiones inspirado en la semántica de las versiones de libtool y en los artículos:
http://www106.pair.com/rhp/parallel.html
NOTA: También recomiendo proporcionar compilación / fecha / personalización / calidad como información adicional (número de compilación, fecha de compilación, nombre del cliente, calidad del lanzamiento):
Hola, la aplicación v2.6.34 para National bank , 2011-05-03 , beta , compilación 23545
¡Pero esta información no es información de versiones!
Recomendaría el estándar de versión semántica, que también parece seguir el sistema de versión de Maven. Por favor consulte,
En resumen, es <major>.<minor>.<patch><anything_else> , y puede agregar reglas adicionales a la parte de cualquier otra cosa que le parezca adecuada. p.ej. -<qualifier>-<build_number> .
Simplemente para completar, mencionaré el antiguo estándar de Apple para los números de versión . Esto se parece a la versión principal . versión menor . Versión de error . etapa Revisión de no lanzamiento . Etapa es un código extraído del conjunto d (desarrollo), a (alfa), b (beta) o fc (envío final del cliente - más o menos lo mismo que el candidato de lanzamiento, creo).
La revisión de la etapa y la no versión solo se utilizan para versiones que no sean las versiones correctas.
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 importante como 2.0. Si desea trabajar hacia 2.0.1, puede comenzar con 2.0.1d1, 2.0.1d2, a 2.0.1d153 o lo que sea que le haya costado, luego enviar 2.0.1a1 a QA, y después de que aprobaron 2.0.1a37 , envíe 2.0.1b1 a algunos apostadores dispuestos, luego, después de 2.0.1b9, sobrevivió una semana en el campo, queme 2.0.1fc1 y comience a firmar. Cuando 2.0.1fc17 obtuviera 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 y rutinas de ayuda en las bibliotecas para hacer comparaciones.
Tenga en cuenta que un esquema de número de versión (como xy0 vs. xy ) puede estar limitado por factores externos.
Considere ese anuncio para Git 1.9 (enero de 2014) :
Un candidato de lanzamiento Git v1.9-rc2 ahora está disponible para pruebas en los lugares habituales.
He escuchado rumores de que a varias herramientas de terceros no les gustan los números de versión de dos dígitos (por ejemplo, "Git 2.0") y comencé a barfing de izquierda a derecha cuando los usuarios instalan v1.9-rc1.
Si bien es tentador reírse de ellos por su presunción descuidada, también soy práctico y no me importa llamar a la próxima versión v1.9.0 para ayudarlos.Si vamos por esa ruta (y estoy inclinado a tomar esa ruta en este momento), el esquema de versiones será:
- La próxima versión candidata será
v1.9.0-rc3, nov1.9-rc3;- La primera versión de mantenimiento para
v1.9.1seráv1.9.1(y Nth one seráv1.9.N); y- El lanzamiento de la función después de v1.9.0 será v1.10.0 o v2.0.0, dependiendo de qué tan grande sea el salto de función que estamos viendo.