¿Cuál es tu método preferido para nombrar tus versiones de software?

Question

¿Cuál es su método preferido para nombrar sus versiones de software? Como Microsoft: alpha - beta - final - service pack ... Como Google: gmail beta - beta - beta - beta - :) Como algunos softwares: 0.2 - 0.3 - 0.9999 ...

Answer 1

Major.Minor.Release.Build

Mientras que los incrementos de Release y Build no deben contener " cambios de ruptura " (por ejemplo, tienen un formato de archivo diferente para almacenar documentos), no estoy absolutamente seguro de si se permiten las versiones menores.

El significado de los sufijos alfa, beta son para mí:

Alpha / Preview: Oye, tengo algo que quiero mostrar.

Beta: el conjunto de características está completo hasta ahora, pero quedan algunos errores.

Release Candidate: creo que no quedan errores (principales).

Final: Podría haber errores aún, pero tengo que liberarlos en algún momento ;-).

Answer 2

No lanzamos software alfa / beta a nuestros clientes. Por lo tanto simplemente usamos:

• x.0 (para las versiones principales, que contiene importantes / muchas características nuevas)
• x.1, x.2, etc. (para versiones menores que contienen nuevas funciones y mejoras menores)
• x.y.1, x.y.2, etc. (para correcciones de errores / versiones de mantenimiento)

(donde x, y = 1,2, ...)

Answer 3

Prefiero el método prototipo, alfa, beta, GA. Esto me permite comunicar el estado actual del software a los usuarios / clientes. Junto con eso, proporciono números de versión .2, .3, .4.

• El primer dígito que representa los hitos principales.
• El segundo dígito representa aumentar la liberación (generalmente lo hago una vez por semana, así que incremento el segundo dígito).
• El tercer dígito se usa para los parches, por lo tanto, si hay un error en el código que se corrige fuera del horario normal de publicación, uso el tercer dígito.

Answer 4

Microsoft usa la numeración de las versiones, así como los nombres alfa, beta y GA.

Creo que la denominación de la versión depende mucho de lo que estás intentando lograr. Si está lanzando algo para el consumo y no está intentando recopilar datos de un período beta, no lo llame beta. Si no está intentando obtener una vista previa de la tecnología, no la llame alfa.

Actualmente trabajo principalmente con aplicaciones web y solo numeramos nuestras versiones como incrementos de enteros según el momento en que implementamos (1, 2, 3, 4, 5, etc.). No hay razón para tener que involucrarse en una lógica de nombres complicada si a nadie le importan las versiones de todos modos.

Answer 5

Para software pequeño solo Major.Minor. Si Cambios principales: algunos archivos de entrada no son compatibles con la versión anterior. No estamos lanzando el software a los clientes, por lo que la misma versión es para pruebas y para el lanzamiento final.

Answer 6

La forma en que hemos estado nombrando nuestros lanzamientos es generalmente el número de fase. Con la mayoría de nuestros contratos siendo proyectos gubernamentales, desplegaremos el primer lanzamiento y luego realizaremos la Fase 2, la Fase 3, la Fase 4 a medida que la entidad decida avanzar junto con las solicitudes de nuevas características (y adquiera fondos para dichos desarrollos futuros). p>

Answer 7

Algunos nombres de proyectos de software de código abierto se publican después de la fecha en que se publicaron. Por ejemplo, Ubuntu 8.04 se lanzó en abril de 2008 y Ubuntu 6.06 se lanzó en junio de 2006. Pero Ubuntu no es la única distribución de Linux que utiliza este método.

Por supuesto, cada versión de Ubuntu también tiene un nombre en código que es, cada vez, un animal diferente, combinado con un adjetivo aliterante (el adjetivo también sirve como una taquigrafía cutre para los iniciados). Cada lanzamiento sube en el alfabeto para que las personas puedan recordar fácilmente dónde colocar un lanzamiento en el flujo constante. Por ejemplo:

por ejemplo 6.06, draco apuesto 6.10, efervescente 7.04, fawn fey 7.10, gibón gutsy

Answer 8

Prefiero la notación del kernel de Linux: major.minor.release.build, pero rara vez uso la parte .build, y no uso números pares / impares para menores de edad estables / en desarrollo.