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

107

¿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.

— rjstelling
fuente

45

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.

— Mike B
fuente

1

Esto tiende a seguir el patrón que he visto utilizado con éxito en muchos proyectos, grandes o pequeños. Es muy efectivo.

— luis.espinal

1

¿Cómo se relaciona / debería "número de compilación" con "identificador de conjunto de cambios (hash)"? ¿Es parte del hash, incremental o algo más?

— Jace Browning

@Jace, donde trabajo, usamos Mercurial y salimos del número del conjunto de cambios. Solo empujamos / extraemos de un único repositorio, por lo que el número no es exclusivo del pago específico. Entonces tenemos [mayor]. [Menor]. [Conjunto de cambios] en consecuencia (aunque los números mayor y menor a menudo son más comerciales que indicativos de progreso desde la última versión).

— Wai Ha Lee

Si llama a ToString () en una estructura de versión .NET, la compilación será el tercer número, no la revisión. Como puede ver con este script de PowerShell:$version = New-Object System.Version 1, 2, 3, 4; $version.ToString(); $version.Build;

— Joel McBeth

¿El "número de compilación" implica que solo se trata de pequeños ajustes como correcciones de errores? ¿Debería alguna nueva funcionalidad al menos obtener su propio número de revisión?

— Kyle Delaney

90

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.

— M. Dudley
fuente

Sorprendido, esto no es obtener más amor.

— Mark Canlas

Llegué un poco tarde a la fiesta ... Agregué esta respuesta 9 meses después de la pregunta original. ;-)

— M. Dudley

Parece que esto resulta ser lo mismo que la política de versiones racionales de RubyGems que mencioné a continuación, solo que mejor formalizada.

— Ken Bloom

@ MarkCanlas no recibe más amor porque une ideas específicas a lo que constituye un lanzamiento mayor / menor / parche. Habla de API que es un poco ... extraño

— Rudolf Olah

55

SemVer está destinado a las API de control de versiones, no al software orientado al usuario: "El software que usa el control de versiones semántico DEBE declarar una API pública". Entonces, técnicamente, no puedes usar SemVer sin una API pública. Sin embargo, podría tener sentido adoptar algo similar a SemVer para versionar aplicaciones orientadas al usuario.

— Ajedi32 01 de

33

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

Año, mes, día, edificio

Auto explicado.

— Maniero
fuente

44

¡Y siempre sabes lo fresco que es tu código ...! :)

— Lipis

3

Esto también es similar a los números de versión de Ubuntu. Lo hacen año.meses Ejemplos: 10.04 y 10.10

— Brad Cupit

55

Vale la pena mencionar que esto solo funciona bien para un sistema que no tiene problemas de compatibilidad (un sitio web) o inherentemente siempre tiene incompatibilidad (una versión de ubuntu).

— jkerian

1

@jkerian, ¿por qué es importante la compatibilidad para esto?

— AviD

12

@AviD: Estoy un poco confundido acerca de por qué preguntas esto, ya que casi todas las demás respuestas a esta pregunta muestran sistemas de versiones que incluyen información de compatibilidad. Su elección depende de la información que desea registrar con sus números de versión. Para mis propósitos, una fecha básicamente no tiene sentido (solo comenzar en v1 e incrementar cada compilación sería una mejora). ¿Alguna vez te ramificaste? ¿alguna vez lanzas "parche nuevo en código antiguo" mientras lanzas "nueva versión"? Pero para algo como un sitio web o un sistema operativo, un sistema basado en fechas parece bastante apropiado.

— jkerian

13

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.

— Ken Bloom
fuente

2

Esto se conoce esencialmente como Versiones

— Patrice M.

2

@PatriceM. Gracias por compartir ese enlace. semver.org no existía cuando escribí esa respuesta.

— Ken Bloom el

10

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:

Numeración ágil 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.

— altern
fuente

Primer enlace inactivo ...............

— Pacerier

8

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.

— Jesse C. Slicer
fuente

2

Parece un uso ineficiente del tiempo y la energía .............

— Pacerier

10

Entonces estaba dejando ese comentario, pero no te detuvo.

— Jesse C. Slicer

Es toda una magnitud menos ......

— Pacerier

7

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.

— Maniero
fuente

Buena idea. ¿De dónde sacaste la idea de "generación"?

— Pacerier

6

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.

— Cascabel
fuente

2

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.

— Gran maestro B
fuente

2

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!

— Jeffrey Cameron
fuente

1

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.

— JBRWilkinson
fuente

1

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)

De esta manera, si alguien usa, digamos, una versión a la 1.5.3que podría decir de un vistazo que podría actualizar para 1.5.4obtener los parches, eso 1.6.0agregaría funcionalidad y que no debería actualizar 2.0.0(al menos sin manejar el cambio).

— Keith
fuente

Semver solo funciona para las API. No productos

— Pacerier

@Pacerier, ¿podrías explicar por qué?

— Keith

Por SemVer mismo. No puede usar SemVer sin una API pública.

— Pacerier

@Pacerier no significa que no pueda usar este patrón para la numeración de versiones.

— Keith

0

              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).

— barjak
fuente