Git, versiones semánticas y cómo encaja en (mi) una línea de tiempo de desarrollo típica?

Estoy trabajando en un sistema de preguntas y respuestas y estoy a punto de etiquetar mi aplicación actual con "1.0.0" para su primera versión / etiqueta oficial. Está a punto de lanzarse para la prueba beta a un público de prueba limitado a continuación. ¿Es correcto "1.0.0" en esta etapa?

Además, sin duda habrá muchos errores encontrados en esa etapa. ¿Lo mantengo como "1.0.0" pero moviendo la etiqueta con fuerza hasta que se lance. O al corregir los errores, ¿le daría una nueva etiqueta "1.0.1". Luego, después de otra ronda de pruebas, tal vez "1.0.2"

Entonces, cuando trabaje en mejoras (por ejemplo, nuevas funciones, como un nuevo menú, un nuevo campo de entrada de búsqueda), ¿se trataría de cambios menores como "1.0.0" a "1.1.0"?

Usted menciona que está buscando usar el control de versiones semántico, así que echemos un vistazo a las especificaciones de control de versiones semántico en http://semver.org/ :

Dado un número de versión MAJOR.MINOR.PATCH, incremente el:

1. Versión PRINCIPAL cuando realiza cambios de API incompatibles,
2. Versión MENOR cuando agrega funcionalidad de una manera compatible con versiones anteriores, y
3. Versión PATCH cuando realiza correcciones de errores compatibles con versiones anteriores.

Las etiquetas adicionales para metadatos previos al lanzamiento y de compilación están disponibles como extensiones para el formato MAJOR.MINOR.PATCH.

y un poco más abajo:

Una versión previa al lanzamiento PUEDE denotarse agregando un guión y una serie de identificadores separados por puntos inmediatamente después de la versión del parche. Los identificadores DEBEN comprender solo caracteres alfanuméricos y guiones ASCII [0-9A-Za-z-]. Los identificadores NO DEBEN estar vacíos. Los identificadores numéricos NO DEBEN incluir ceros a la izquierda. Las versiones preliminares tienen una precedencia menor que la versión normal asociada. Una versión previa al lanzamiento indica que la versión es inestable y podría no satisfacer los requisitos de compatibilidad previstos, como se indica en su versión normal asociada. Ejemplos: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

Entonces, si está lanzando una versión beta verdadera de su versión 1.0, debe etiquetarla 1.0.0-beta(o similar de acuerdo con las especificaciones). Si usted va a tener varias versiones beta a medida que corregir errores, a continuación 1.0.0-beta.1, 1.0.0-beta.2, etc.

Cuando agrega funciones que son compatibles con versiones anteriores, debe incrementar el número MENOR. Si realiza muchos cambios internos que causarían cambios importantes en otra parte de su aplicación, entonces ese es un cambio MAYOR. Si está haciendo cambios menos dramáticos (por ejemplo, solo agrega código y no cambia el comportamiento del código existente), entonces esto sería un cambio MENOR. Si tiene una aplicación pesada de UI y cambia completamente esa UI, también diría que es un cambio MAYOR también (la UI puede considerarse la API para los usuarios finales).

En cuanto a cómo agregar indicadores a su repositorio de git, le sugiero que primero cree una 1.xrama. Esto le permitirá seguir fácilmente todo en la versión 1 mientras permite el desarrollo continuo de la versión 2 en master. Luego etiqueta la versión beta con una etiqueta 1.0.0-beta(o -beta.1si habrá varias versiones beta). Una vez que corrija todos los errores que necesita corregir, etiquete la 1.0.0versión real . Luego etiquete cada lanzamiento según sea necesario.

Puede echar un vistazo a algunos flujos de trabajo probados y verdaderos para git como git flow y github flow para obtener ideas sobre cómo desea configurar su flujo de trabajo continuo.

Además, si desea un poco más de contexto sobre las versiones semánticas para programas sin una API, esta respuesta se profundiza.

Sí, actualice el número de versión todo el tiempo que se salga de su control y entre en el de otra persona.

la razón es que no necesita saber con qué estaban trabajando. Cuando vuelve la prueba y dice "encontramos un error en la versión 1.0.0", lo último que quiere es decir "¿qué versión 1.0.0, la que le dimos el lunes o la actualizada que le di el viernes? "

La actualización del 3er número está realmente diseñada para esto, la diferencia funcional entre 1.0.0 y 1.0.999 debe ser limitada, cuando agrega grandes características nuevas, luego actualiza el segundo número. Sin embargo, agregar un nuevo campo de entrada de búsqueda realmente no cuenta como un cambio lo suficientemente grande como para garantizar una actualización del segundo número, pero YMMV.

Personalmente, tiendo a usar el segundo número no tanto para las actualizaciones de funciones sino para marcar un "lanzamiento completo", es decir, uno que haya pasado por la prueba y haya pasado. Luego actualizo ese valor y repito el intercambio entre dev y test, incrementando el 3er número cada vez hasta que todo pase.

Ya se han dado buenas respuestas, pero también encontraría una forma de incorporar el git sha1 en su aplicación, por lo que puede encontrar que fue git commit 1b5619273127398123 el que se utilizó en esta versión en particular. De esa manera, si el Sr. Smith de BigCo llama y se queja de que su aplicación no funciona correctamente, puede preguntar "¿Cuál es la larga fila de dígitos y letras en el segundo trabajo cuando hace clic en Acerca de?", Y git checkout NNNNNNpara obtener exactamente eso versión, luego siga los mismos pasos que hizo el Sr. Smith y (con suerte) reproduzca el problema. No hay nada peor que tratar de encontrar un problema que no puedes reproducir porque estás usando una versión sutilmente diferente (donde por casualidad o a propósito evitas ese problema en particular).

También asegúrese de que su sistema de compilación esté incluido en la versión, que incluye preferiblemente qué versión del compilador, etc.