Estoy buscando un esquema de numeración de versiones que expresa la magnitud del cambio, especialmente de compatibilidad.

Apache APR, por ejemplo, usar el bien conocido esquema de numeración de versiones

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

Maven sugiere una similar, pero más detallado esquema:

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

Donde se Maven esquema de control de versiones definido? Existen convenios para el calificador y el número de compilación? Probablemente es una mala idea usar maven, pero no para seguir la versión de Maven esquema de …

¿Qué otra versión esquemas de numeración ¿sabes? ¿Qué esquema prefiere y por qué?

InformationsquelleAutor deamon | 2010-01-12

5 Comentarios

  1. 25

    Aquí es el actual Maven versión de algoritmo de comparación, y un discusión de ella. Mientras sólo para las versiones de crecer, y en todos los campos, excepto el número de compilación se actualizan de forma manual, ya está bueno. Los calificadores de trabajo como: si uno es un prefijo de los otros, no es más. De lo contrario, la comparación alfabéticamente. El uso de ellos para pre-releases.

    La adscripción de la utilización de la semántica de control de versiones para expresar la compatibilidad; importante es no compatible cambios de menor importancia para compatible con versiones anteriores características, parche compatible con versiones anteriores correcciones de errores. Documento para que la biblioteca los usuarios pueden expresar sus dependencias en su biblioteca correctamente. Sus instantáneas son automáticos y no tiene el incremento de estos, excepto la primera instantánea después de un lanzamiento a causa de la manera en que los prefijos son comparados.

  2. 23

    Yo recomendaría la Semántica de control de Versiones estándar, que Maven sistema de control de versiones también parece seguir. Por favor, echa un vistazo,

    http://semver.org/

    En resumen es <major>.<minor>.<patch><anything_else>, y usted puede agregar reglas adicionales a las de cualquier otra cosa que parte como parece ajuste a usted. por ejemplo. -<qualifier>-<build_number>.

    • El -<calificador>-<build_number> esquema de Maven parece no coincidir exactamente con la semver.org recommondation. semver.org: «Una versión especial número PUEDE ser denotado por anexando una cadena arbitraria inmediatamente después de la versión del parche. La cadena DEBE estar compuesto de sólo caracteres alfanuméricos más dash [0-9A-Za-z] y DEBE comenzar con un carácter alfabético [a-Za-z]
    • semver.org probablemente cambió de años atrás, pero por el registro que cumple ahora con maven esquema: «Una versión de pre-lanzamiento PUEDE ser denominado añadiendo un guión y una serie de puntos separados identificadores inmediatamente después de la versión del parche. Identificadores DEBE contener sólo caracteres alfanuméricos ASCII y guión [0-9A-Za-z]. Los identificadores NO DEBE estar vacío. Identificadores numéricos NO DEBE incluir los ceros a la izquierda. «
    • Los formatos no son del todo compatibles, porque el algoritmo de comparación de semver es mucho más complicado que lo utiliza Maven. Pero si nos atenemos a simplemente «-RC1», «-RC2» o similar, usted debe estar bien.
  3. 6

    Puramente para la integridad, voy a mencionar la viejo Apple estándar para los números de versión. Esto se parece a versión principal. menor de la versión. error de la versión. etapa. no-liberación de revisión. El escenario es un código que se dibuja a partir del conjunto d (desarrollo), un (alfa), b (beta), o fc (final de la nave del cliente – más o menos la misma que la release candidate, creo).

    El escenario y no la liberación de revisión sólo se utilizan para las versiones cortas de una adecuada versiones.

    Así, la primera versión de algo que podría ser 1.0.0. Usted podría haber publicado una corrección de errores como 1.0.1, una nueva versión (con más funciones), la 1.1, y una reescritura o actualización importante como 2.0. Si luego quería trabajar hacia 2.0.1, usted podría empezar con 2.0.1d1, 2.0.1d2, en 2.0.1d153 o lo que llevó a que, a continuación, enviar 2.0.1a1 al control de calidad, y después de que se aprobó 2.0.1a37, enviar 2.0.1b1 a algunos dispuestos los apostadores, a continuación, después de la 2.0.1b9 sobrevivido una semana en el campo, quemar 2.0.1fc1 y empezar a signoffs. Cuando 2.0.1fc17 tengo suficiente, sería 2.0.1, y no sería mucho regocijo.

    Este formato fue suficientemente estandarizado que hubo un lleno formato binario para ella, y rutinas auxiliares en las bibliotecas para hacer comparaciones.

    • Puramente para la integridad ( 🙂 ), me gustaría señalar que, en mi humilde opinión, necesidad de disponer de versiones para cada etapa (que este esquema implica) no es una buena idea. Al menos el que se construye para el final de QA/testing debe trabajar en la producción sin cambios. Cualquier diferencias en el comportamiento debe ser inyectado a través de la configuración. Ver, por ejemplo, Separar ‘debug’ y ‘liberación’ construye?.
    • No creo que eso implica separar construye para cada etapa. Si usted está en la beta-fase de pruebas, usted podría crear 1.2.3b4 en dev, puesto que a través de CI, obtener control de calidad para aprobar, ¿UAT, y luego se extienda a los beta-testers, utilizando el mismo código binario en todo el camino. Más bien, lo que esto implica es que, en cualquier momento, sabe usted hasta qué punto una generación podría ir – así que usted sabe que cuando se confirma que sólo podrá ser utilizado en el desarrollo, enviado a los probadores beta, liberado, etc. Hay duplicidad en las transiciones, por ejemplo, si 1.2.3b10 pasa la prueba beta, el mismo código, probablemente se convertirá en 1.2.3fc1, que no es lo ideal.
  4. 4

    Después de leer un montón de artículos/QAs/preguntas frecuentes/libros he vuelto a pensar
    que [IMPORTANTES].[MENOR].[REV] es más útil para el control de versiones de esquema para
    describir la compatibilidad entre versiones del proyecto (control de versiones de esquema
    para desarrolladores, no para la comercialización).

    PRINCIPALES cambios hacia atrás es incompatible y exigir el cambio de
    nombre del proyecto, la ruta de acceso a los archivos, Guid, etc.

    MENOR cambios es compatible con versiones anteriores. Marca la introducción de nuevos
    características.

    REV para la seguridad o correcciones de errores. Hacia adelante y hacia atrás compatible.

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

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

    NOTA: también recomiendo proporcionar construir/fecha/custom/calidad como información adicional (construir
    número, fecha de fabricación, nombre del cliente, la liberación de la calidad):

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

    Pero esta info es no control de versiones info!

  5. 0

    Tenga en cuenta que un número de versión de esquema (como x.y.0 vs x.y) puede ser afectada por factores externos.

    Considerar que anuncio de Git 1.9 (Januaury 2014):

    Una release candidate Git v1.9-rc2 está ahora disponible para las pruebas en los lugares de costumbre.

    He oído rumores de que varias herramientas de terceros no como la de dos dígitos de los números de versión (por ejemplo, «Git 2.0») y comenzó a barfing a la izquierda y a la derecha cuando los usuarios instalar la v1.9-rc1.

    Aunque es tentador para reírse de ellos por su descuidado supuesto, yo también soy práctico y
    no le importa llamar la próxima versión v1.9.0, para ayudar a ellos.

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

    • El próximo lanzamiento de los candidatos será v1.9.0-rc3, no v1.9-rc3;
    • La primera versión de mantenimiento para v1.9.0 será v1.9.1 (y Enésima ser v1.9.N); y
    • La función después de la liberación de v1.9.0 será v1.10.0 o v2.0.0, dependiendo de lo grande que la función de salto que estamos mirando.

Dejar respuesta

Please enter your comment!
Please enter your name here