¿Qué esquema de numeración de versiones recomienda?

Esto es lo que usamos en nuestra empresa: Major.Menor. Versión de parche. Número de compilación.

El cambio mayor implica un ciclo completo de lanzamiento, incluyendo la participación en la comercialización, etc. Este número está controlado por fuerzas ajenas a la I + D (por ejemplo, en uno de los lugares donde trabajé, Marketing decidió que nuestra próxima versión sería '11', para igualar a un competidor. Estábamos en la versión 2 en ese momento :)).

Menor se cambia cuando una nueva característica o se agrega un cambio de comportamiento importante al producto.

La versión del parche aumenta una vez cada vez que se agrega un parche oficialmente a la versión, generalmente incluyendo solo correcciones de errores.

Build Version se usa cuando se lanza una versión especial para un cliente, generalmente con una corrección de error específica para él. Por lo general, esa corrección se enrollará para el próximo parche o versión menor (y la administración de productos generalmente marca el error como "se lanzará para el parche 3" en nuestro seguimiento sistema).

Nuestro departamento de I + D utiliza 1.0.0.0.0.000: MAYOR.menor.parche.audiencia.situación crítica.build

Por Favor, por favor, , no hagas eso.

Soy un gran fan de Versionado semántico

Como muchos otros han comentado, esto usa el formato X. Y. Z y da buenas razones de por qué.

Este tipo de pregunta tiene más que ver con la guerra religiosa que con aspectos objetivos. Siempre hay toneladas de pros y contras contra un esquema de numeración u otro. Todo lo que la gente podría (o debería) darte es el esquema que usaron y por qué lo eligieron.

Por mi parte, uso un esquema X. Y. Z todos son números donde:

• X indica un cambio en la API pública que introduce incompatibilidad hacia atrás
• Y indicar una adición de algunos características
• Z indica una corrección (ya sea corrigiendo un error, ya sea cambiando la estructura interna sin afectar la funcionalidad)

Eventualmente, utilizo el sufijo "Beta N" si quiero algunos comentarios de los usuarios antes de que se realice una versión oficial. No hay sufijo " RC " ya que nadie es perfecto y siempre habrá errores; -)

Personalmente prefiero MAYOR.MENOR.BUGFIX-SUFIJO donde el SUFIJO es dev para las versiones de desarrollo (version control checkouts), rc1 / rc2 para release candidates y sin sufijo para release versions.

Si tiene sufijos para las comprobaciones de desarrollo, tal vez incluso con el número de revisión, no hay necesidad de hacerlos pares/impares para mantenerlos separados.

Preferimos major.minor.milestone.revision-build esquema, donde:

• major: Incrementos sobre cambios arquitectónicos significativos o avances importantes en capacidades.
• minor: Pequeños cambios y nuevas características que no requieren cambios arquitectónicos.
• milestone: Indica la estabilidad y madurez del código:
  • 0 para el desarrollo / pre-alfa
  • 1 para alfa
  • 2 para beta
  • 3 para release candidate (RC)
  • 4 para versión final / producción
• revision: Indica el número de lanzamiento, parche o corrección de error.
• build: Referencias únicas a compilaciones o versiones específicas de una aplicación. El número de compilación es un entero secuencial, normalmente incrementado en cada compilación.

Ejemplos:

• 1.4.2.0-798: Primera versión beta de la versión 1.4, creada por build number 798.
• 1.8.3.4-970: 1.8-RC4, creado por build number 970.
• 1.9.4.0-986: Primera producción lanzamiento de la versión 1.9, creada por build number 986.
• 1.9.4.2-990: Segunda corrección de error de la versión 1.9, creada por el número de compilación 990.

Dado que las versiones de prodcution siempre tienen 4 en su 3er dígito de la cadena de versión, el dígito puede eliminarse para las versiones de producción.

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.

Las versiones menores significan cosas diferentes para diferentes proyectos, pero generalmente no necesitan preservar la compatibilidad de fuentes.

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

Escribí más sobre el rationale here .

Con las prácticas ágiles de desarrollo de software y las aplicaciones SaaS, la idea de una versión Mayor vs.una versión Menor ha desaparecido - las versiones salen con mucha frecuencia de forma regular - por lo que un esquema de numeración de versiones que se basa en esta distinción ya no es útil para mí.

Mi empresa utiliza un esquema de numeración que toma los últimos 2 dígitos del año en que comenzó la publicación, seguido del número de publicación dentro de ese año.

Por lo tanto, el 4º lanzamiento iniciado en 2012 sería 12.4.

Puede incluir un número de versión "bug fix" después de eso si es necesario, pero lo ideal es que esté publicando con suficiente frecuencia que estos no son a menudo necesarios, por lo que "12.4.2".

Este es un esquema muy simple y no nos ha dado ninguno de los problemas de otros esquemas de numeración de versiones que he usado antes.

La diferencia entre una política de número de versión cerrada y de código abierto también puede provenir de un aspecto comercial , cuando la versión principal puede reflejar el año de la publicación, por ejemplo.

Lo que solíamos hacer aquí es mayor.menor.plataforma.fix .

Mayor: Aumentamos este número cuando el archivo guardado de esta compilación ya no es compatible con la compilación anterior.
Ejemplo : Los archivos guardados en la versión 3.0.0.0 no serán compatibles con la versión 2.5.0.0.

Menor: Aumentamos este número cuando se ha añadido una nueva característica. Esta característica debe ser vista por el usuario. No es una característica oculta para developper. Este número se restablece a 0 cuando mayor se incrementa.

Platform: Esta es la plataforma que utilizamos para el desarrollo.
Exemple : 1 significa.net framework version 3.5.

Fix : Aumentamos este número cuando solo se incluyen correcciones de errores con esta nueva versión. Este número se restablece a 0 cuando se incrementa mayor o menor.

Simplemente

Major.Minor.Revision.Build