Obtener números de versión de software correctos. v1.0.0.1 [cerrado]

https://stackoverflow.com/questions/134517

02-07-2019
|

Pregunta

Distribuyo software en línea y siempre me pregunto si hay una manera 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?

Solución

Estoy empezando a gustarme la convención Year.Release [.Build] que usan algunas aplicaciones (por ejemplo, Perforce). Básicamente solo dice el año en que lanzas y la secuencia dentro de ese año. Por lo tanto, 2008.1 sería la primera versión, y si lanzaras otra unos meses o tres más tarde, iría a 2008.2.

La ventaja de este esquema es que no hay " magnitud " de lanzamiento, donde entra en discusiones sobre si una característica es lo suficientemente importante como para garantizar un incremento de versión principal o no.

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

Otros consejos

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

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

No lance la misma versión dos veces: una vez que se lance la versión 1.0.0 a nadie, nunca podrá volver a lanzarla.
Los números de lanzamiento deberían aumentar monotónicamente. 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 publicar correcciones para versiones anteriores mientras haya versiones más nuevas disponibles; consulte GCC, por ejemplo:

GCC 3.4.6 se lanzó 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.

Entonces, debe crear su esquema de numeración de versiones con cuidado.

Otro punto en el que creo firmemente:

El número de versión de lanzamiento no está relacionado con la numeración de versión del sistema CM (VCS), excepto para programas triviales. Cualquier software serio 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, ya que cambia demasiado impredecible.

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

Por cierto, sé de software que pasó por versiones de la versión 1.00 a la 9.53, pero que luego cambió a 2.80. Ese fue un grave error, dictado por el marketing. Por supuesto, la versión 4.x del software está / era obsoleta, por lo que no causó confusión de inmediato, pero la versión 5.x del software todavía está en uso y se vende, y las revisiones ya han alcanzado la 3.50. Estoy muy preocupado por lo que va a hacer mi código que tiene que funcionar tanto con 5.x (estilo antiguo) como con 5.x (estilo nuevo) cuando ocurra el inevitable conflicto. Supongo que tengo que esperar que se demoren un poco al cambiar a 5.x hasta que el viejo 5.x realmente esté muerto, pero no soy optimista. También utilizo un número de versión artificial, como 9.60, para representar el código 3.50, de modo que pueda hacer pruebas sensatas 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 ... gruñir ... gruñir ...

NB : Eric Raymond proporciona Guía de práctica de lanzamiento de software incluyendo la sección (vinculada) sobre nombrar (numerar) lanzamientos.

Usualmente uso D como contador de compilación (incremento automático por compilador) Incremento C cada vez que se lanza una compilación a & Quot; public & Quot; (no todas las compilaciones se lanzan) A y B se utilizan como número de versión mayor / menor y se cambian manualmente.

Creo que hay dos formas de responder a esta pregunta, y no son completamente complementarias.

Técnico: Incrementar versiones basadas en tareas técnicas. Ejemplo: D es el número de compilación, C es la iteración, B es una versión menor, A es una versión principal. Definir lanzamientos menores y mayores es realmente subjetivo, pero podría estar relacionado con cosas como cambios en la arquitectura subyacente.
Marketing: Incremente las versiones según cuántos " new " o " útil " Se proporcionan características a sus clientes. También puede vincular los números de versión a una política de actualización ... Los cambios a A requieren que el usuario compre una licencia de actualización, mientras que otros cambios no.

El resultado final, creo, es encontrar un modelo que funcione para usted y sus clientes. He visto algunos casos en los que las versiones pares son lanzamientos públicos, y las versiones impares se consideran beta o lanzamientos de desarrollo. He visto algunos productos que ignoran C y D todos juntos.

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

Nuestra política:

A - Cambios significativos (> 25%) o adiciones en funcionalidad o interfaz.
B - pequeños cambios o adiciones en funcionalidad o interfaz.
C - cambios menores que Romper la interfaz.
D - correcciones a un construir que no cambian el interfaz.

Las personas tienden a querer hacer esto mucho más difícil de lo que realmente necesita ser. Si su producto tiene una sola rama de larga duración, solo nombre las versiones sucesivas por su número de compilación. Si tiene algún tipo de & Quot; las correcciones de errores menores son gratuitas, pero debe pagar por las nuevas versiones principales & Quot ;, luego use 1.0, 1.1 ... 1.n, 2.0, 2.1. .. etc.

Si no puede averiguar de inmediato cuáles son A, B, C y D en su ejemplo, entonces obviamente no los necesita.

El único uso que hice del número de versión fue para que un cliente me dijera que está usando 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 deben ser de solo 1 dígito .

1.1.2.3

está bien, pero

1.0.1.23

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

Los números de compilación de incremento automático a menudo dan como resultado números de versión como

1.0.1.12537

que tampoco ayuda realmente.

Un esquema bueno y no técnico solo usa la fecha de compilación en este formato:

AAAA.MM.DD.BuildNumber

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

Ejemplos: 2008.03.24.1 o 2008.03.24.14503

Esto es principalmente para lanzamientos internos, los lanzamientos públicos verían la versión impresa como 2008.03 si no lanzas más de una vez al mes. Las versiones de mantenimiento se marcan como 2008.03a 2008.03b y así sucesivamente. Raramente deberían pasar & Quot; c & Quot; pero si lo hace, es un buen indicador que necesita un mejor control de calidad y / o procedimientos de prueba.

Los campos de versión que comúnmente ve el usuario deben imprimirse en un " marzo de 2008 " formato, reserve la información más técnica en el cuadro de 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 utilizando la lista de cambios de control de versiones como último número y verificando eso para determinar si la fecha también debe cambiarse.

Yo uso V.R.M ej. 2.5.1

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

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

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

Solo eche un vistazo a todas las respuestas, todas muy diferentes.

Personalmente, uso Major.Minor.*.*: donde Visual Studio completa el número de revisión / compilación automáticamente. Esto se usa donde yo trabajo también.

En esta nota técnica de Apple se describe un buen esquema de versiones fácil de usar originado en el antiguo Mac OS: http://developer.apple.com/technotes/tn/tn1132.html

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

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, lo difícil que será una actualización.

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

Los lanzamientos menores significan cosas diferentes para diferentes proyectos, pero generalmente no necesitan preservar la compatibilidad de origen.

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

Escribí más sobre la justificación aquí .

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

De http://semver.org/ :

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

Versión MAYOR cuando realiza cambios de API incompatibles, versión MENOR   cuando agrega funcionalidad de una manera compatible con versiones anteriores y PATCH   versión cuando realiza correcciones de errores compatibles con versiones anteriores. Adicional   Las etiquetas para metadatos de prelanzamiento y compilación están disponibles como extensiones   al formato MAJOR.MINOR.PATCH.

Para el desarrollo interno, utilizamos el siguiente formato.

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

Por ejemplo, si estoy lanzando la aplicación # 15 hoy, y es la tercera actualización este mes, entonces mi versión # será

15.2008.9.3

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

Para las últimas seis versiones principales, hemos utilizado M.0.m.b donde M es la versión principal, m es la versión secundaria yb es el número de compilación. Las versiones lanzadas incluyen 6.0.2, 7.0.1, ..., hasta 11.0.0. No pregunte por qué el segundo número siempre es 0; He preguntado varias veces y nadie lo sabe realmente. No hemos tenido un cero diferente desde que se lanzó 5.5 en 1996.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow