¿Cuándo no se debe etiquetar una confirmación de versión?

Contexto: Hace poco me enteré de las versiones semánticas , y estoy tratando de determinar la mejor manera de usarlo prácticamente para mis propios proyectos.

Dado que semver toma en cuenta cambios importantes, cambios menores y parches para el control de versiones, ¿cuándo no se debe etiquetar una confirmación con una versión actualizada? Me parece que cada cambio encajaría en una de estas categorías, por lo que cada cambio debería ser versionado, pero cuando miro varios proyectos populares en GitHub, esta no parece ser la forma en que se hacen las cosas (solo mirando el hecho de que los proyectos grandes tienen decenas de miles de confirmaciones, con solo cientos de etiquetas).

SemVer se refiere a versiones de versiones , no confirmaciones . Si su modelo de control de versiones requiere que cada commit para master sea una versión, entonces sí, cada commit deberá etiquetarse de acuerdo con el grado del cambio.

Sin embargo, en general, los proyectos desarrollan un producto mayormente estable en master y etiquetan los lanzamientos que consideran dignos de soporte. Cuando lo hagan, etiquetarán de acuerdo con su esquema de versiones, que no necesariamente tiene que ser SemVer en particular.

Los números de versión se asignan a las versiones. En general, no todas las confirmaciones deben ser una versión. Hay varias razones para esto.

En primer lugar, mientras dice que "prueba" cada confirmación, hay niveles de prueba. Ejecutar una prueba automática en una máquina está muy bien, pero en un software complejo probablemente no captará todos los problemas. Algunos problemas pueden ser específicos del hardware o la configuración, algunos problemas pueden estar más relacionados con consideraciones subjetivas humanas que con requisitos difíciles de comprobar.

En segundo lugar, encontrar el número de versión principal debería ser una acción rara. Básicamente significa que todo lo que depende de su software debe verificarse manualmente para ver si depende de alguna de las características eliminadas.

Una consecuencia de esto es que solo debe agregar funciones a su "API pública" en versiones completas (no alfa / beta) si está preparado para admitir esas funciones en su forma actual a largo plazo.

En tercer lugar, es útil mantener baja la cantidad de versiones en uso generalizado. Incluso en una rama estable, a menudo es mejor reunir una serie de arreglos y hacer una única versión que hacer una versión para cada arreglo.

Parece obvio decirlo, pero: el propósito de los números de versión es permitirle determinar fácilmente qué versión del software está ejecutando cualquiera.

Si hay alguna posibilidad de que alguien tenga acceso a una iteración particular del código, y no pueda determinar fácilmente un identificador único, entonces esa iteración debería tener un número de versión único. Veo esto como la 'primera regla'. Como consecuencia, las versiones distintas claramente querrán números de versión distintos.

Sin embargo, entra más en juego:

Una forma de estar seguro de esto es aumentar los números de versión con cada confirmación, pero esto no suele ser una buena idea. Puede tomar varias confirmaciones / iteraciones para que funcione un cambio relativamente pequeño, y es confuso para el mundo exterior ver la versión 0.0.1 -> 0.0.2 como resultado de una gran cantidad de cambios acumulados y luego 0.0.2 -> 0.0 .56 porque alguien cometió un espacio en blanco corrige un archivo a la vez y no cambió nada funcional.

En realidad, qué tan lejos de "una versión por versión completa" a "una versión para cada confirmación" depende de usted: los otros usuarios y qué sistemas está dispuesto a utilizar para llenar los vacíos.

Personalmente, estoy acostumbrado a trabajar en proyectos pequeños, y estoy feliz de usar hash git hasta una versión que otros usan y una versión de prueba para cada uno de estos (no importa cuán pocas personas espero tener en sus manos). Sin embargo, en compañías más grandes y proyectos más grandes, se usa algo fuera de los números de versión semántica, pero una fidelidad más baja que cada confirmación, como la numeración de candidatos de lanzamiento. Estos tienen ventajas pero agregan complejidad.

Se debe versionar cada solicitud de extracción que se fusiona con la maestra.

Si no debería ser una nueva versión (al menos un parche), probablemente no debería fusionarse para masterizar porque la característica / arreglo / etc no está completa.

Sin embargo, dependiendo del flujo de trabajo de su equipo, aún podría terminar con múltiples confirmaciones para dominar sin una versión. Si hay varias confirmaciones en una solicitud de extracción que no se aplastan (no deberían, en mi opinión), aún puede terminar con 10 confirmaciones y solo 1 nueva versión.