Obtener los números de versión del software correctos. v1.0.0.1

Question

Distribuyo software en línea y siempre me pregunto si existe una forma adecuada de definir mejor los números de versión.

Supongamos que A.B.C.D en las respuestas. ¿Cuándo aumenta cada uno de los componentes?

¿Utiliza algún otro truco de número de versión, como D mod 2 == 1, significa que es solo un lanzamiento interno?

¿Tiene versiones beta con sus propios números de versión, o tiene versiones beta por número de versión?

Answer 1

estoy empezando a gustar la [.build] convención Year.Release que algunas aplicaciones (por ejemplo, Perforce) utilizan. Básicamente, solo dice el año en que lanzas y la secuencia dentro de ese año. Entonces, 2008.1 sería la primera versión, y si publicara otra uno meses o tres más tarde, iría a 2008.2.

La ventaja de este esquema es que no hay implícita "magnitud" de la liberación, en la que entrar en discusiones acerca de si una característica es lo suficientemente importante como para justificar un incremento de versión importante o no.

Un extra opcional es etiquetar el número de compilación, pero eso tiende a ser solo para fines internos (por ejemplo, se agrega al archivo EXE/DLL para que pueda inspeccionar el archivo y asegurarse de que esté allí).

Answer 2

Yo uso V.R.M, p. 2.5.1

V (versión) cambios son una importante reescritura
R (revisión) cambios se nuevas características significativas o correcciones de errores
M (modificación) cambios son correcciones de bux menores (errores tipográficos, etc)

A veces uso un número de confirmación SVN al final también.

Answer 3

Nuestra política:

• A - significativa (> 25%) cambios o adiciones en funcionalidad o interfaz.
• B - pequeños cambios o adiciones en la funcionalidad o interfaz .
• C - cambios menores que rompen la interfaz.
• D - se corrige una construcción que no cambia la interfaz .

Answer 4

Las personas tienden a querer hacer esto mucho más difícil de lo que realmente necesita ser. Si su producto tiene solo una sola sucursal de larga vida, solo nombre las versiones sucesivas por su número de compilación. Si tienes algún tipo de "correcciones de errores menores son gratuitas, pero tienes que pagar por nuevas versiones importantes", utiliza 1.0, 1.1 ... 1.n, 2.0, 2.1 ... etc.

Si no puede determinar de inmediato qué representan A, B, C y D en su ejemplo, entonces obviamente no los necesita.

Answer 5

normalmente utilizo D como un contador de construcción (incremento automático por el compilador) I de la subasta C cada vez que se libera una acumulación de "público" (no cada generación se libera) A y B se utilizan como mayor/menor versión número y cambiado manualmente.

Answer 6

Creo que hay dos formas de responder a esta pregunta, y no son del todo elogiosas.

1. Técnico: Incremente las versiones basadas en tareas técnicas. Ejemplo: D es el número de compilación, C es iteración, B es una versión menor, A es una versión mayor. Definir versiones menores y principales es realmente subjetivo, pero podría estar relacionado con cosas como cambios en la arquitectura subyacente.
2. Comercialización: Incremente las versiones según la cantidad de funciones "nuevas" o "útiles" que se le brinden a sus clientes. También puede vincular los números de versión a una política de actualización ... Los cambios en A requieren que el usuario adquiera una licencia de actualización, mientras que otros no.

La conclusión, creo, es encontrar un modelo que funcione para usted y sus clientes. He visto algunos casos en los que las versiones pares son publicaciones públicas y las versiones impares se consideran versiones beta o dev. He visto algunos productos que ignoran C y D todos juntos.

Luego está el ejemplo de Micrsoft, donde la única explicación racional a los números de versión para .NET Framework es que el marketing estaba involucrado.

Answer 7

El único uso que he hecho del número de versión era para que un cliente me podría decir que están utilizando la versión 2.5.1.0 o lo que sea.

Mi única regla está diseñada para minimizar los errores al informar ese número: los cuatro números tienen que ser de 1 dígito solamente.

1.1.2.3 

está bien, pero

1.0.1.23 

no lo es. Es probable que los clientes denuncien ambos números (verbalmente, al menos) como "uno-uno-dos-tres".

incremento automático números de compilación a menudo se traduce en números de versión como

1.0.1.12537 

que en realidad no ayuda, tampoco.

Answer 8

Para el desarrollo interno, utilizamos el siguiente formato.

[Program #] . [Year] . [Month] . [Release # of this app within the month] 

Por ejemplo, si estoy liberando aplicación # 15 hoy en día, y es la tercera actualización de este mes, entonces mi versión # será

15.2008.9.3 

Es totalmente no estándar, pero es útil para nosotros

Answer 9

Durante los últimos seis versiones principales, hemos utilizado M.0.m.b donde M es la versión principal, m es la versión menor, y b es el número de compilación. Las versiones liberadas incluían 6.0.2, 7.0.1, ..., hasta 11.0.0. No preguntes por qué el segundo número es siempre 0; Lo he preguntado varias veces y nadie sabe realmente. No hemos tenido un no-cero allí desde 5.5 fue lanzado en 1996.

Answer 10

Un buen esquema y no técnica sólo utiliza la fecha de creación en este formato:

YYYY.MM.DD.BuildNumber

Donde BuildNumber es un número continuo (lista de cambios) o simplemente comienza de nuevo en 1 cada día.

Ejemplos: 2008.03.24.1 o 2008.03.24.14503

Esto es principalmente para los comunicados internos, comunicados públicos verán la versión impresa como 2008.03 si no se libera con más frecuencia que una vez al mes. Las versiones de mantenimiento se marcan como 2008.03a 2008.03b y así sucesivamente. Raramente deberían pasar por "c", pero si lo hace es un buen indicador de que necesita mejores procedimientos de control de calidad y/o pruebas.

Los campos de versión que el usuario ve comúnmente deberían imprimirse en un formato amigable de "marzo de 2008", reserve la información más técnica en el diálogo Acerca de o en los archivos de registro.

Mayor desventaja: simplemente compilar el mismo código en otro día podría cambiar el número de versión. Pero puede evitar esto usando la lista de cambios de control de versiones como último número y comprobando en contra de eso para determinar si también se debe cambiar la fecha.

Answer 11

En mi opinión, casi cualquier esquema de número de versión se puede hacer funcionar más o menos sanamente. El sistema en el que trabajo utiliza números de versión como 11.50.UC3, donde la U indica el Unix de 32 bits, y el C3 es un número de revisión menor (fixpack); otras letras se usan para otros tipos de plataforma. (No recomendaría este esquema, pero funciona.)

Existen algunas reglas de oro que hasta ahora no se han establecido, pero que están implícitas en lo que la gente ha discutido.

• No lance la misma versión dos veces: una vez que la versión 1.0.0 se haya lanzado a nadie, nunca podrá volver a publicarse.
• Los números de versión deberían aumentar monótonamente. Es decir, el código en la versión 1.0.1 o 1.1.0 o 2.0.0 siempre debe ser posterior a la versión 1.0.0, 1.0.9 o 1.4.3 (respectivamente).

Ahora, en la práctica, las personas tienen que liberar correcciones para las versiones anteriores, mientras que las versiones más recientes están disponibles - ver GCC, por ejemplo:

• GCC 3.4.6 fue liberado después de 4.0.0, 4.1.0 (y AFAICR 4.2.0), pero continúa la funcionalidad de GCC 3.4.x en lugar de agregar las características adicionales agregadas a GCC 4.x.

Por lo tanto, debe crear cuidadosamente su esquema de numeración de versiones.

Otro punto, que creo firmemente en:

• El número de versión de lanzamiento no está relacionada con el CM (VCS) versión del sistema de numeración, a excepción de los programas triviales. Cualquier pieza seria de software con más de un archivo fuente principal tendrá un número de versión no relacionado con la versión de un solo archivo.

Con SVN, puede usar el número de versión de SVN, pero probablemente no lo haga ya que cambia de manera impredecible.

Para las cosas con las que trabajo, el número de versión es una decisión puramente política.

Por cierto, conozco el software que pasó por versiones de la versión 1.00 a la 9.53, pero que luego cambió a 2.80.Eso fue un gran error, dictado por el marketing. De acuerdo, la versión 4.x del software está/estaba obsoleta, por lo que no generó confusión de inmediato, pero la versión 5.x del software todavía está en uso y se vendió, y las revisiones ya llegaron a 3.50. Estoy muy preocupado por lo que mi código tiene que funcionar con el 5.x (estilo antiguo) y el 5.x (estilo nuevo) va a funcionar cuando se produce el conflicto inevitable. Supongo que tengo que esperar que se dediquen diligentemente a cambiar a 5.x hasta que el antiguo 5.x realmente esté muerto, pero no soy optimista. También uso un número de versión artificial, como 9.60, para representar el código 3.50, para que pueda hacer una prueba sensata de if VERSION > 900, en lugar de tener que hacer: if (VERSION >= 900 || (VERSION >= 280 && VERSION < 400), donde represento la versión 9.00 por 900. Y luego está el cambio significativo introducido en la versión 3.00.xC3 - mi esquema no puede detectar cambios en el nivel de versión menor ... ... se quejan se quejan ...

NB: Eric Raymond ofrece Software Release Practice HOWTO incluyendo la sección (vinculados) sobre la denominación (numeración).

Answer 12

Todo es realmente subjetivo al final del día y simplemente depende de usted/su equipo.

Solo eche un vistazo a todas las respuestas ya - todas muy diferentes.

Personalmente uso Major.Minor.*.* - Donde Visual Studio rellena automáticamente el número de revisión/construcción. Esto se usa donde yo también trabajo.

Answer 13

Un buen esquema de versiones fácil de usar se originó en el viejo Mac OS se describe en esta nota técnica de Apple: http://developer.apple.com/technotes/tn/tn1132.html

Answer 14

me gusta Year.Month.Day. Entonces, v2009.6.8 sería la "versión" de esta publicación. Es imposible de duplicar (razonablemente) y es muy claro cuando algo es una versión más nueva. También puedes soltar los decimales y hacerlo v20090608.

Answer 15

En el caso de una biblioteca, el número de versión le informa sobre el nivel de compatibilidad entre dos versiones, y por lo tanto, qué tan difícil será una actualización.

Una versión de corrección de errores necesita preservar la compatibilidad binaria, de origen y de serialización.

Las versiones pequeñas significan cosas diferentes para diferentes proyectos, pero generalmente no necesitan preservar la compatibilidad de la fuente.

Los números de la versión principal pueden romper las tres formas.

Escribí más sobre la razón de ser here.

Answer 16

En el mundo de github, se ha hecho popular seguir las especificaciones "semver" de Tom Preston-Werner para los números de versión.

De http://semver.org/:

un número de versión MAJOR.MINOR.PATCH, incremente el:

versión mayor cuando se realizan cambios de API incompatibles, versión menor cuando se agrega funcionalidad en un backwards- manera compatible, y PATCH versión cuando se hacen correcciones de errores compatibles con versiones anteriores. Las etiquetas adicionales para metadatos preliminares y de compilación están disponibles como extensiones en el formato MAJOR.MINOR.PATCH.