¿Qué "convención de nomenclatura de versión" utiliza? [cerrado]

¿Las convenciones de nomenclatura de diferentes versiones son adecuadas para diferentes proyectos? ¿Qué usas y por qué?

Personalmente, prefiero un número de compilación en hexadecimal (por ejemplo, 11BCF), este debe incrementarse muy regularmente. Y luego, para los clientes, un número de versión simple de 3 dígitos, es decir, 1.1.3.

1.2.3 (11BCF) <- Build number, should correspond with a revision in source control
^ ^ ^
| | |
| | +--- Minor bugs, spelling mistakes, etc.
| +----- Minor features, major bug fixes, etc.
+------- Major version, UX changes, file format changes, etc.

Raramente estoy completamente de acuerdo con Jeff Atwood, pero tiendo a seguir su opinión sobre la convención .NET de numeración de versiones .

(Versión principal). (Versión secundaria). (Número de revisión). (Número de compilación)

La mayoría de las veces, para proyectos personales, encuentro que esto es excesivo. Las pocas veces que trabajé en proyectos importantes, como los motores de búsqueda en C #, me apegué a esta convención y pude usarla como un rastreador interno de manera efectiva.

La versión semántica ( http://semver.org/ ) merece una mención aquí. Es una especificación pública para un esquema de versiones, en forma de [Major].[Minor].[Patch]. La motivación de este esquema es comunicar el significado con el número de versión.

No lo uso, pero lo he visto y es una estructura interesante:

Año, mes, día, edificio

Auto explicado.

Intento usar la política RubyGems Rational Versioning en la que:

• El número de versión principal se incrementa cuando se rompe la compatibilidad binaria
• El número de versión menor se incrementa cuando se agrega nueva funcionalidad
• El número de compilación cambia para corregir errores.

Aquí hay un enfoque muy detallado para la numeración de versiones:

• N.x.K, donde Ny Kson enteros. Ejemplos: 1.x.0, 5.x.1, 10.x.33. Utilizado para construcciones intermedias .
• N.M.K, Donde N, My Kson números enteros. Ejemplos: 1.0.0, 5.3.1, 10.22.33. Utilizado para lanzamientos .
• N.x.x, donde Nes entero. Ejemplo: 1.x.x. Utilizado para ramas de soporte .
• N.M.x, donde Ny Mson enteros. Ejemplo: 1.0.x. Usado para liberar ramas .

Aquí está la imagen para una ilustración simple del enfoque de numeración de versiones:

PAsignifica pre-alfa A significa alfa B significa beta AR significa liberación alfa BR significa liberación beta RC significa candidato de liberación ST significa estable

Las ventajas de dicho enfoque de numeración de versiones son las siguientes:

• Representa detalles del ciclo de vida ágil de desarrollo de software .
• Tiene en cuenta los detalles de la estructura del repositorio de código fuente .
• Se explica por sí mismo para aquellos que se acostumbraron a los patrones. Cada patrón representa un artefacto diferente. Dichos patrones se pueden analizar y utilizar fácilmente para otros fines, como el seguimiento de problemas.
• Conjunto de patrones de control de versiones, que es básico para el enfoque de control de versiones descrito y puede usarse para recopilar métricas y planificación .
• Se centra en los conceptos de madurez y nivel de calidad . Muy a menudo, los números de versión como 1.0.0 se asignan sin mucha necesidad (cuando el software está en alfa profundo). El enfoque de numeración de versiones presentado permite establecer varios niveles de madurez. En el caso más simple, tendrá solo dos niveles: build intermedio ( N.x.K) y release ( N.M.K). Lanzamiento significa que el software con el número de versión completo ( N.M.K) ha pasado por algún tipo de proceso de gestión de calidad dentro de la empresa / organización / equipo proveedor.
• Es una evidencia de la naturaleza ágil tanto del desarrollo como de las pruebas.
• Fomenta el enfoque modular de la estructura y arquitectura del software.

También hay un diagrama más complejo que representa el enfoque de versiones en detalles. También puede encontrar diapositivas de presentación útiles que describen la transición al enfoque de versiones y la aplicación SCMFViz que ilustra los principios básicos del enfoque de numeración de versiones. Las diapositivas de presentación también explican por qué es importante mantener el mismo enfoque de versiones durante toda la vida del proyecto de software.

Personalmente, mi actitud hacia el uso de la versión con fecha en lugar de los números de versión reales supone que los desarrolladores del software con versiones con fecha:

• No se sabe nada sobre el ciclo de vida del desarrollo de software . El desarrollo suele ser ágil e iterativo. El enfoque de numeración de versiones debe representar la naturaleza iterativa del proceso de desarrollo de software.
• No me importa la calidad del software . El control y la garantía de calidad son ágiles e iterativos. Al igual que el desarrollo. Y el número de versión debe ser la evidencia de la naturaleza ágil e iterativa tanto del desarrollo como del control / aseguramiento de la calidad.
• No importa la arquitectura o la idea de su aplicación. El número de versión principal ( Nin N.M.K) es responsable tanto de la solución arquitectónica como del principio subyacente de la aplicación. El número de versión principal Nse debe cambiar de acuerdo con los cambios en la arquitectura o los cambios de las ideas y principios principales de su funcionamiento / funcionamiento.
• No tiene control sobre su base de código . Probablemente solo haya una rama (troncal) y se usa para todo. Lo que personalmente no creo que sea correcto, ya que alienta a la base de código a convertirse en un gran basurero.

Este enfoque puede parecer un poco controvertido, pero creo que esta es la forma más directa de dar números de versión apropiados al software.

Para cada versión principal que lanzas, no es raro tener una versión funcional que la llames internamente. Por ejemplo, en mi último trabajo, nos referimos a una versión principal con la siguiente convención de nomenclatura inspirada en Ubuntu:

[condición enfermiza] [nombre del animal aliterativo]

Que dio nombres como " Limp Lamprey ", " Wounded Wombat " y " Asthmatic Anteater ".

Asegúrese de que no sea un nombre realmente genial que no se filtre a sus clientes.

Generation.Version.Revision.Build (9.99.999.9999)

La generación rara vez cambia. Solo un gran giro en el producto: DOS -> Windows, reingeniería completa.

La versión es para grandes cambios incompatibles, nueva funcionalidad, cambios en algunos paradigmas específicos del software, etc.

La revisión a menudo se realiza (características menores y corrección de errores).

Construir es información interna.

git describeproporciona una buena extensión a cualquier convención de numeración que haya elegido. Es bastante fácil integrar esto en su proceso de construcción / empaquetado / implementación.

Supongamos que nombra sus versiones de lanzamiento etiquetadas ABC (major.minor.maintenance). git describeen un commit determinado encontrará el antepasado etiquetado más reciente del commit, luego agregará el número de commits desde entonces y el SHA1 abreviado del commit:

1.2.3-164-g6f10c

Si realmente está en una de las versiones, por supuesto, obtendrá la etiqueta (1.2.3).

Esto tiene el gran beneficio de hacerle saber exactamente de qué fuente construyó, sin tener que numerar cada compilación usted mismo.

Major.Minor.Public (build) [alpha / beta / trial], como "4.08c (1290)"

• Con Major siendo el número de versión principal (1, 2, 3 ...)
• Menor es una versión menor de 2 dígitos (01, 02, 03 ...). Por lo general, el dígito de las decenas se incrementa cuando se agrega una nueva funcionalidad significativa, las que solo se utilizan para corregir errores.
• Público es el lanzamiento público de la compilación (a, b, c, d, e), que a menudo es diferente de la versión menor si una versión menor nunca se lanza como una actualización pública
• build, que es el número de compilación real del que el compilador realiza un seguimiento.
• con TRIAL, ALPHA, BETA X o RC X anexados para esos casos especiales.

Prefiero números de versión que asignan algún significado semántico. Siempre que pueda usar el número de versión para rastrear los errores reportados con una versión en particular a los cambios que ocurrieron en el código fuente (y en su sistema de gestión de actividades), entonces probablemente esté utilizando el método correcto.

Uso .NET, así que estoy atascado con el sistema de numeración de versiones .NET, pero trato de dar un significado semántico a los números, así que con

major.minor.build.revision

• mayor = (hasta el proyecto)
• menor = (hasta el proyecto)
• build = número de compilación de Hudson (puede usar TeamCity o TeamBuild, etc. aquí)
• revisión = revisión de subversión o bazar (dependiendo del proyecto y de su uso)

Siempre nos aseguramos de que el número de versión sea visible de alguna manera (con nuestros programas basados ​​en la consola por lotes se imprime en la consola y un archivo de registro, con las aplicaciones web en la barra de menú en la parte superior generalmente)

De esta manera, si los clientes informan problemas, podemos usar el número de versión para rastrear si están usando la última versión y cuántos problemas hemos tenido con versiones particulares.

¡Se trata de trazabilidad!

Usamos Major.Minor.Build # .YYMMDD [sufijo], ya que generalmente solo hacemos una compilación de producción en un día en particular (pero usamos el sufijo ab / c / d si hay más de uno) y el YYMMDD brinda a los usuarios / clientes / administración una indicación de la antigüedad de la compilación, donde 6.3.1389 no.

Los números importantes aumentan con características significativas del producto (pago).

Los números menores aumentan con correcciones / mejoras (actualización gratuita).

La construcción siempre aumenta; no todas las construcciones se envían, por lo que no es una progresión lineal.

Los números de versión deben tener suficiente información para evitar conflictos y corregir un error en los problemas de tipo de versión incorrecta, pero no deben transmitir información adicional que no sea relevante.

Por ejemplo, si usa la fecha, los clientes pueden decir que tienen una versión anterior, y los parches contra versiones antiguas pueden tener versiones confusas.

Personalmente, me gustan las versiones semánticas :

• Los lanzamientos son Major. Minor.Patch
• Patch aumenta cada vez que liberas una compilación.
• Minor aumenta cada vez que se agrega funcionalidad compatible con versiones anteriores.
• Major aumenta cuando la nueva funcionalidad no es compatible con versiones anteriores.
• Cuando Major== 0 estás en alfa / pre-lanzamiento. Major> = 1 son sus lanzamientos públicos.
• Los números más bajos se restablecen a 0 cada vez que incrementa, así que

  1.5.3-> 1.5.4(corrección de errores) -> 1.6.0(característica menor) -> 2.0.0(cambio de ruptura)

              1.0.0
                El |
              1.0.1
                El |
(público 1.0) 1.0.2 -----
                El | \
              2.0.0 1.1.0
                El | El |
              2.0.1 1.1.1 (público 1.1)
                El |
(público 2.0) 2.0.2 -----
                El | \
              3.0.0 2.1.0
                         El |
                       2.1.1 (público 2.1)
                         El |
                       2.2.0
                         El |
                       2.2.1

X.Y.Zes nuestro número interno de versión. X.Yes el número de versión pública, el que tiene un significado para nuestros clientes. Cuando una X.Y.Zversión se hace pública, nunca habrá una X.Y.(Z+1)versión: la versión pública siempre es la última de la serie.

X se incrementa cuando se lanza una versión principal.

Y se usa para las ramas de mantenimiento de esas versiones principales, solo para la corrección de errores.

Zse usa internamente y no tiene un significado fijo. Hasta ahora, creo una nueva Zversión cuando creo que la aplicación tiene un conjunto de características que son interesantes para mostrar a los no desarrolladores, y es relativamente estable. De esta manera, puedo mostrar una demostración de la "última versión válida conocida" de la aplicación cuando alguien pregunta una. En un futuro cercano, planeo usar las Zversiones numéricas para nombrar un "objetivo" de características, en nuestro rastreador de errores.

Como nota al margen, usamos maven (con el releasecomando) para incrementar el número de versión. Entonces, también hay X.Y.Z-SNAPSHOTversiones (que indica cualquier versión entre X.Y.(Z-1)y X.Y.Z).