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

30

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).

VortixDev
fuente
23
¿ Cada compromiso de dominar un lanzamiento estable, probado y de calidad garantizada en su proyecto?
Alex Reinking
1
@AlexReinking Cada confirmación se prueba, pero solo estoy tratando de acostumbrarme a las prácticas comunes con mis proyectos personales, así que solo soy yo quien lo trabaja y, como tal, no hay realmente un sistema que no sea "hacer un cambio, probar yo mismo, lo comprometo ".
VortixDev
También tenga en cuenta que las etiquetas se pueden cambiar más tarde. El único identificador de confirmación sólido es la clave hash de confirmación.
Thorbjørn Ravn Andersen
99
cada compromiso para dominar ??? nunca debes comprometerte a dominar. Cada fusión para dominar suena mucho mejor.
xyious
2
Creo que @xyious da en el clavo. Cada commit que termine en master debe etiquetarse con una versión porque cada commit en master debe ser una fusión de lanzamiento de desarrollo .
BJ Myers

Respuestas:

71

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.

Alex Reinking
fuente
55
SemVer en su mayoría solo tiene sentido para las bibliotecas donde el usuario tiene otros bits de código y no humanos. Realmente no hay cambios "importantes" en la mayoría de las aplicaciones orientadas al usuario porque el usuario puede adaptarse automáticamente a la nueva versión.
Qwertie
55
Yo diría que las versiones de línea de comandos de las aplicaciones orientadas al usuario deben tener una versión semántica ya que sus banderas y formatos de salida pueden comportarse de manera diferente. Un poco de un área gris.
Alex pensando de nuevo el
55
@Qwertie Las expectativas del usuario son menos rígidas que las expectativas del software, pero aún existen. DEFINITIVAMENTE he usado muchas piezas de software que han emitido lo que consideraría cambios "rotos" en su interfaz o funcionalidad. Decidir qué constituye un lanzamiento mayor o menor es ciertamente más subjetivo que con las bibliotecas, pero esa no es necesariamente una razón para evitarlo.
Iron Gremlin
11
@Qwertie: frena la actualización. ¿Cuántas personas aún ejecutan versiones principales antiguas de Windows y Office?
Alex Reinking
55
@Qwertie Pueden inspirarse para leer detenidamente el registro de cambios o la documentación para que puedan adaptar la forma en que usan el sistema para hacer uso de características nuevas o modificadas, o encontrar soluciones para una característica que se ha eliminado. Es el mismo caso, su uso del software debe cambiar porque el software ha cambiado, por lo que debe informarles sobre ese cambio sin ambigüedades.
Iron Gremlin
11

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.

Peter Green
fuente
2

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.

Alguien
fuente
0

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.

xyious
fuente