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

https://stackoverflow.com/questions/121795

02-07-2019
|

Pregunta

Mi pregunta es qué esquema de nomenclatura de versiones se debe utilizar para qué tipo de proyecto.

Muy común es major.minor.fix, pero incluso esto puede llevar al número 4 (es decir,Firefox 2.0.0.16).Algunos tienen un modelo en el que los números impares indican versiones para desarrolladores y los números pares, versiones estables.Y todo tipo de adiciones pueden entrar en la mezcla, como -dev3, -rc1, SP2, etc.

Existen razones para preferir un esquema sobre otro y deberían realizarse diferentes tipos de proyectos (es decir,Código abierto vs.Código cerrado) ¿tienen diferentes esquemas de nombres de versiones?

Solución

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

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

Para en casa aplicaciones, donde los usuarios nunca solicitaron la aplicación, la implementación está a cargo de TI y los usuarios llamarán al servicio de asistencia técnica, encontré que Year.Month.Day.Build funciona mejor en muchas situaciones.Por lo tanto, este número de versión se puede descodificar para proporcionar información más útil al servicio de asistencia técnica que el esquema de número de versión público.

Sin embargo, al final del día, haría una recomendación por encima de todo: Utilice un sistema que pueda mantener consistente.Si hay un sistema que puede configurar/programar para que su compilador lo use automáticamente cada vez, usa eso.

Lo peor que puede pasar es que publiques archivos binarios con el mismo número de versión que los anteriores. Recientemente he estado lidiando con informes de errores de red automatizados (aplicación de otra persona) y llegué a la conclusión de que el Año.Mes.Día. Los números de versión de compilación que se muestran en los volcados de núcleo no estaban ni remotamente actualizados con la aplicación en sí (la aplicación en sí usaba una pantalla de presentación con los números reales, que por supuesto no se extrajeron del binario como se podría suponer).El resultado es que no tengo forma de saber si los volcados de memoria provienen de un binario de 2 años (lo que indica el número de versión) o de un binario de 2 meses y, por lo tanto, no hay forma de obtener el código fuente correcto (¡tampoco hay control de fuente! )

Otros consejos

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

El Importante El cambio implica un ciclo de lanzamiento completo, incluida la participación en marketing, etc.Este número está controlado por fuerzas ajenas a 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 cambia cuando se agrega una nueva característica o un cambio de comportamiento importante al producto.

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

Versión de compilación se utiliza 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 solución se implementará para el próximo parche o versión menor (y la Gerencia de Producto generalmente marca el error como "se lanzará para el parche 3" en nuestro sistema de seguimiento).

Soy un gran fan de Versionado semántico

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

Nuestro departamento de I+D utiliza 1.0.0.0.0.000:MAYOR.menor.patch.audience.critical_situation.build

Por favor, por favor, no hagas eso.

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

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

X indicar un cambio en la API pública que introduce incompatibilidad con versiones anteriores
Y indicar una adición de algunas características
z indicar una solución (ya sea corregir un error o cambiar la estructura interna sin afectar la funcionalidad)

Finalmente, uso el sufijo "Beta N" si quiero recibir comentarios de los usuarios antes de que se realice un lanzamiento oficial.No hay sufijo "RC", ya que nadie es perfecto y siempre habrá errores ;-)

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

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

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

major:Incrementos ante cambios arquitectónicos significativos o avances importantes en las capacidades.
minor:Pequeños cambios y nuevas funcionalidades 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 liberación (RC)
- 4 para lanzamiento final/producción
revision:Indica el número de versión, parche o corrección de errores.
build:Referencias únicas a compilaciones o versiones específicas de una aplicación.El número de compilación es un número entero secuencial, que generalmente se incrementa en cada compilación.

Ejemplos:

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

Dado que los lanzamientos de producción siempre tienen 4 en el tercer dígito de la cadena de versión, el dígito puede eliminarse para lanzamientos de producción.

En el caso de una biblioteca, el número de versión le informa sobre la nivel de compatibilidad entre dos versiones y, por tanto, lo difícil que será una actualización.

Una versión de corrección de errores debe preservar la compatibilidad binaria, de código fuente y de serialización.

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

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

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

Con prácticas de desarrollo de software ágiles y aplicaciones SaaS, la idea de una Major vs.una versión menor ha desaparecido (las versiones aparecen con mucha frecuencia y de forma regular), por lo que un esquema de numeración de versiones que se base en esta distinción ya no me resulta útil.

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

Entonces, la cuarta versión iniciada en 2012 sería la 12.4.

Puede incluir un número de versión de "corrección de errores" después de eso si es necesario, pero lo ideal es que los publique con la frecuencia suficiente para que no sean necesarios, por lo tanto, "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 una aspecto comercial, cuando la versión principal puede reflejar el año de lanzamiento, por ejemplo.

Lo que solíamos hacer aquí es corrección.de.plataforma.menor.mayor.

importante:Aumentamos este número cuando los archivos guardados de esta compilación ya no son compatibles 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 característica.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 nivel mayor.

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

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

Simplemente

Major.Minor.Revision.Build

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

No afiliado a StackOverflow