it-swarm-es.com

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

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

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.

47
Mike B

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

90
M. Dudley

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

Año, mes, día, edificio

Auto explicado.

33
Maniero

Intento usar política de 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.
14
Ken Bloom

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

  • N.x.K, donde N y K son enteros. Ejemplos: 1.x.0, 5.x.1, 10.x.33. Utilizado para ¡compilaciones intermedias.
  • N.M.K, donde N, M y K son enteros. Ejemplos: 1.0.0, 5.3.1, 10.22.33. Utilizado para ¡lanzamientos.
  • N.x.x, donde N es entero. Ejemplo: 1.x.x. Utilizado para ramas de soporte.
  • N.M.x, donde N y M son enteros. Ejemplo: 1.0.x. Utilizado para ¡liberar ramas.

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

Agile version numbering

PA significa pre-alfa A significa alfa B significa beta AR significa alfa-release BR significa beta- liberar RC significa liberar candidato ST significa estable

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

  • Representa detalles de ¡ciclo de vida de desarrollo de software ágil.
  • Tiene en cuenta los detalles de ¡estructura del repositorio de código fuente.
  • Es ¡autoexplicativo 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 se puede usar 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, solo tendrá dos niveles: ¡construcción intermedia (N.x.K) y ¡lanzamiento (N.M.K). Versión significa esa pieza de 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 ¡naturaleza ágil tanto del desarrollo como de las pruebas.
  • Alienta ¡enfoque modular a la estructura y arquitectura del software.

También hay más complejo diagrama que representa el enfoque de versiones en detalles. También puede encontrar útil diapositivas de presentación que describe la transición al enfoque de versiones y SCMFViz aplicación 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 ¡versión de fecha en lugar de números de versión reales supone que los desarrolladores del software con versiones fechadas:

  • 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 idea de su aplicación. Número de versión principal (N en 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 N debe cambiarse de acuerdo con los cambios en la arquitectura o los cambios en 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.

10
altern

Para cada versión principal que publique, no es raro tener una versión funcional que la llame 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 animal aliterativo]

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

8
Jesse C. Slicer

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.

7
Maniero

git describe proporciona una extensión agradable 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.

Suponga que nombra sus versiones de lanzamiento etiquetadas A.B.C (major.minor.maintenance). git describe en 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 beneficio agradable de hacerle saber exactamente de qué fuente construyó, sin tener que numerar cada compilación usted mismo.

6
Cascabel

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í)
  • revision = Subversion o revisión de Bazar (dependiendo del proyecto y de lo que esté usando)

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 generalmente en la barra de menú en la parte superior)

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!

2
Jeffrey Cameron

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.
2
GrandmasterB

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

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

X.Y.Z Es nuestro número de versión interno. X.Y Es el número de versión pública, el que tiene un significado para nuestros clientes. Cuando una versión X.Y.Z Se hace pública, nunca habrá una versión X.Y.(Z+1): 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.

Z se usa internamente y no tiene un significado fijo. Hasta ahora, creo una nueva versión Z 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 versiones de número Z para nombrar un "objetivo" de características, en nuestro rastreador de errores.

Como nota al margen, usamos maven (con el comando release) para incrementar el número de versión. Por lo tanto, también hay versiones X.Y.Z-SNAPSHOT (Que indica cualquier versión entre X.Y.(Z-1) y X.Y.Z).

0
barjak