2009-01-04 11 views

Respuesta

22

Major.Minor.Release.Build

Si bien los incrementos de liberación y compilación no deben contener "cambios de interrupción" (por ejemplo, tienen un formato de archivo diferente para almacenar documentos), no estoy del todo seguro de si se permiten las versiones menores.

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

Alfa/Vista previa: Oye, tengo algo que quiero mostrar.

Beta: El conjunto de características está completo hasta ahora, pero aún quedan algunos errores.

Release Candidate: Creo que no quedan errores (importantes).

Final: Aún pueden existir errores, pero tengo que liberarlos en algún momento ;-).

1

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

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

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

  • x.0 (para las versiones principales, que contiene importantes/un montón de nuevas características)
  • X.1, X.2, etc. (para versiones menores que contienen nuevas características y mejoras menores)
  • xy1, xy2, etc. (por correcciones de errores/versiones de mantenimiento)

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

0

Para software pequeño solo Major.Minor. Si Major cambia, 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 la versión final.

1

Microsoft utiliza la numeración de versiones, así como los moniker alfa, beta y GA.

Creo que la nomenclatura de versiones depende en gran medida de lo que se intenta lograr. Si está liberando algo para el consumo y no está tratando de 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 enumeramos nuestras versiones como números enteros en aumento cuando implementamos (1, 2, 3, 4, 5, etc.).No hay razón para tener que entrar en una lógica de nombres complicada si a nadie le importan las versiones de todos modos.

0

La forma en que hemos estado nombrando nuestras versiones suele ser el número de fase. Con la mayoría de nuestros contratos como proyectos del gobierno, lanzaremos la primera versión y luego realizaremos la Fase 2, la Fase 3, la Fase 4 mientras la entidad decide avanzar junto con las nuevas solicitudes de funciones (y adquiere fondos para dichos desarrollos futuros).

0

Algunos lanzamientos de nombres de proyectos de software de código abierto después de la fecha de lanzamiento. 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 clave que es cada vez un animal diferente, combinado con un adjetivo alitizador (el adjetivo también sirve como una taquigrafía cursi 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, Drake pulcro 6,10, 7,04 EFT nervioso , leonado luchadora 7,10, gibón agallas

0

prefiero el kernel Linux notación: major.minor.release.build, pero yo raramente usa la parte .build, y no uso números par/impar para menores estables/de desarrollo.

Cuestiones relacionadas