versioning - last - ¿Qué esquema de numeración de versión recomiendas?

package json version (13)

Mi pregunta es, qué esquema de denominación de versión se debe usar para qué tipo de proyecto.

Muy común es major.minor.fix, pero incluso esto puede llevar a 4 números (es decir, Firefox 2.0.0.16). Algunos tienen un modelo que los números impares indican versiones de desarrollador e incluso números estables. Y todo tipo de adiciones puede ingresar a la mezcla, como -dev3, -rc1, SP2, etc.

¿Existen razones para preferir un esquema sobre otro y si los diferentes tipos de proyectos (es decir, Código abierto vs. Código cerrado) tienen diferentes esquemas de nombres de versión?

Este tipo de pregunta es más acerca de la guerra de la religión que los aspectos objetivos. Siempre hay un montón de pros y contras contra un esquema de numeración u otro. Todo lo que la gente podría (o debería) darle es el esquema que usaron y por qué lo eligieron.

Por mi parte, uso un esquema XYZ todos son números donde:

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

Eventualmente, uso el sufijo "Beta N" si quiero algún comentario de los usuarios antes de que se realice una publicación oficial. Sin sufijo "RC" ya que nadie es perfecto y siempre habrá errores ;-)

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

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

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

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

La Versión de compilación se usa cuando se lanza una versión especial para un cliente, generalmente con una corrección de errores específica para él. Por lo general, ese arreglo se acumulará para el próximo parche o versión menor (y Product Management generalmente marca el error como "se lanzará para el parche 3" en nuestro sistema de seguimiento).

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

Lo que solíamos hacer aquí es major.minor.platform.fix .

principal : 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 agrega una nueva función. Esta característica debe ser vista por el usuario. No es una característica oculta para el desarrollador. Este número se restablece a 0 cuando se incrementa el principal.

plataforma : esta es la plataforma que utilizamos para el desarrollo.
Ejemplo : 1 significa .net framework versión 3.5.

solución : aumentamos este número cuando solo se incluyen correcciones de errores en esta nueva versión. Este número se reinicia a 0 cuando se incrementa el mayor o el menor.

Nuestro departamento de I + D usa 1.0.0.0.0.000: MAJOR.minor.patch.audience.critical_situation.build

Por favor, por favor , no hagas eso.

Personalmente prefiero MAJOR.MINOR.BUGFIX-SUFFIX donde SUFFIX es desarrollador para versiones de desarrollo (controles de versiones), rc1 / rc2 para candidatos de lanzamiento y sin sufijo para versiones de lanzamiento.

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

Simplemente

Major.Minor.Revision.Build

Hay dos buenas respuestas para esto (más muchas preferencias personales, ver el comentario de Gizmo sobre guerras religiosas)

Para aplicaciones públicas , el estándar Major.Minor.Revision.Build funciona mejor como IMO: los usuarios públicos pueden saber fácilmente qué versión del programa tienen y, hasta cierto punto, qué tan desactualizada es su versión.

Para las aplicaciones internas , donde los usuarios nunca solicitaron la aplicación, la implementación es manejada por TI, y los usuarios llamarán a la mesa de ayuda, encontré el Year.Month.Day.Build para que funcione mejor en muchas situaciones. Por lo tanto, este número de versión se puede decodificar para proporcionar más información útil a la mesa de ayuda y luego el esquema de número de versiones públicas.

Sin embargo, al final del día, haría una recomendación sobre todo: usa un sistema que puedas mantener coherente . Si hay un sistema que puede configurar / script su compilador usará automáticamente cada vez, use eso .

Lo peor que puede pasar es que libere binarios con el mismo número de versión que los anteriores. Recientemente he estado lidiando con informes de error de red automatizados (aplicación de otras personas), y llegué a la conclusión de que el Año.Mes.Día. Cree los números de versión que se muestran en los volcados del núcleo donde ni remotamente estén actualizados con la aplicación en sí (la aplicación utilizó una pantalla de bienvenida con los números reales, que por supuesto no se extrajeron del binario como cabría suponer). El resultado es que no tengo forma de saber si los volcados de falla proceden de un binario de 2 años (lo que indica el número de versión) o un binario de 2 meses, y por lo tanto no hay forma de obtener el código fuente correcto (¡tampoco el control de fuente! )

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, fuente y serialización.

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

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

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

Soy un gran admirador de las versiones semánticas

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

Con las prácticas de desarrollo de software Agile y las aplicaciones SaaS, la idea de una versión Mayor vs. Menor ha desaparecido, los lanzamientos salen con mucha frecuencia regularmente, por lo que un esquema de numeración de versiones que se base en esta distinción ya no me sirve.

Mi compañía usa un esquema de numeración que toma los últimos 2 dígitos del año en que comenzó el lanzamiento, seguido por el número de versión dentro de ese año.

Por lo tanto, la cuarta versión iniciada en 2012 sería 12.4.

Si es necesario, puede incluir un número de versión de "corrección de errores", pero lo ideal es que esté liberando con la frecuencia necesaria para que no sea necesario, 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 anteriormente.

Nosotros preferimos major minor milestone . revision - esquema de build , donde:

major : Incrementos en 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 estabilidad y madurez del código:
- 0 para desarrollo / pre-alfa
- 1 para alfa
- 2 para beta
- 3 para candidato de lanzamiento (RC)
- 4 para la versión final / producción
revision : indica liberación, parche o número de corrección de errores.
build : referencias únicas a construcciones específicas o versiones de una aplicación. El número de compilación es un entero secuencial, generalmente incrementado en cada compilación.

Ejemplos:

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

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

Esta discusión previa puede ayudar.