Versión de prueba antes de iniciar un nuevo desarrollo o al etiquetar un lanzamiento, ¿cuál es mejor?

Algunos proyectos topan la versión antes de iniciar un nuevo desarrollo, mientras que otros proyectos topan la versión al etiquetar un lanzamiento.

¿Qué enfoque es mejor?

Si el número de versión no cambia al comienzo de la nueva fase, los desarrolladores pueden olvidarse de cambiarlo y simplemente lanzar el programa.

Si el número de versión cambió antes del lanzamiento de la etiqueta, entonces 2 los números de versión (etiqueta y Makefile / AssemblyInfo.cs) no coinciden.

git describe puede darle v1.2.3.4-15-g1234567 si la revisión actual es posterior a v1.2.3.4, pero ya ha cambiado los archivos para tener v1.2.3.5

La razón principal para el número de versión está ahí, de modo que cuando se descubre un error, puede depurar utilizando la versión real del código fuente en la que realmente ocurrió el error (descubriendo así la razón real del error).

No importa qué esquema de versiones utilice, siempre que el usuario de su producto pueda comunicar al desarrollador suficiente información para que el desarrollador pueda lograr este objetivo.

Otros motivos para el control de versiones son los equipos de marketing y ayuda (a veces legales).
Estos equipos tienen sus propias prioridades para el control de versiones.

• Ayuda
  Quiere una manera fácil de determinar la compatibilidad, las características y la estabilidad potencial (consulte el esquema de números pares / impares de Linux).
• El marketing
  quiere un número mayor cada vez (preferiblemente por encima de 2)
• Legal
  Quiere asegurarse de tener todas las funciones comprometidas antes de aumentar el número.

En todos los casos, el esquema utilizado no es importante. Siempre y cuando sea coherente (o tenga fácilmente disponible documentación altamente detallada sobre cambios de significado).

Cuando utilizo números de versión de cuatro segmentos como los ensamblados .NET, prefiero usar una etiqueta de control de versión para establecer los primeros tres segmentos, luego el cuarto segmento es el número de confirmaciones desde esa etiqueta.

Por ejemplo, una versión se etiqueta "v1.2.3". Si git-describedevuelve "v1.2.3-4-g1a2b3c4", cuando se construye ese ensamblado se versiona como 1.2.3.4.

Si luego se aplica una etiqueta a esa versión, git-describese devolverá "v1.2.4", que representa la versión 1.2.4.0. La próxima confirmación sería 1.2.4.1.

Los beneficios que encuentro de este sistema son:

• Cada confirmación incrementa automáticamente el número de versión.
• Una versión se puede hacer una versión ".0" simplemente etiquetándola.
• Aunque no es perfecto, este sistema funciona con DVCS porque cuenta el número de confirmaciones desde la etiqueta más reciente.