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

8

Estoy trabajando en un sistema de preguntas y respuestas A y a punto de etiquetar mi aplicación actual con "1.0.0" para su primera versión / etiqueta oficial. Está a punto de ser implementado para pruebas beta en una audiencia de prueba limitada. ¿Es correcto "1.0.0" en esta etapa?

Además, sin duda habrá muchos errores encontrados en esa etapa. Lo guardo como "1.0.0" pero muevo la etiqueta a la fuerza hasta que se libere. 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, al trabajar en mejoras (por ejemplo, nuevas funciones como un nuevo menú, nuevo campo de entrada de búsqueda), ¿serían cambios menores desde "1.0.0" a "1.1.0"?

    
pregunta Martyn 30.01.2015 - 09:44

3 respuestas

7

Menciona que está considerando el uso de versiones semánticas, así que veamos la especificación de las versiones semánticas en enlace :

  

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

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

Las etiquetas adicionales para el lanzamiento previo y los metadatos 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 incluir solo caracteres alfanuméricos ASCII y guión [0-9A-Za-z-]. Los identificadores NO DEBEN estar vacíos. Los identificadores numéricos NO DEBEN incluir ceros iniciales. Las versiones preliminares tienen una prioridad menor que la versión normal asociada. Una versión preliminar indica que la versión es inestable y puede que no cumpla con 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 liberas una versión beta verdadera de tu versión 1.0, deberías etiquetarla 1.0.0-beta (o similar según la especificación). Si va a tener varias versiones beta para corregir errores, entonces 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 podrían causar cambios importantes en otras partes de su aplicación, entonces ese es un cambio IMPORTANTE. Si está realizando cambios menos dramáticos (por ejemplo, solo agrega el código y no cambia el comportamiento del código existente), esto sería un cambio MENOR. Si tiene una aplicación pesada de UI y la cambia completamente, también diría que es un cambio PRINCIPAL (la UI puede considerarse la API para los usuarios finales).

En cuanto a cómo para agregar indicadores a su repositorio git, le sugiero que primero cree una rama 1.x . 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.1 si habrá múltiples betas). Una vez que haya solucionado todos los errores que necesita arreglar, etiquete la versión real 1.0.0 . Luego etiqueta cada lanzamiento según sea necesario.

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

Además, si desea un poco más de contexto sobre el control de versiones semántico para programas sin API, esta respuesta va en cierta profundidad.

    
respondido por el cbojar 30.01.2015 - 15:44
3

Sí, actualice el número de versión todo el tiempo que se mueva fuera de su control y de otro.

la razón es que necesitas saber con qué trabajaban. Cuando vuelve la prueba y dice "encontramos un error en la versión 1.0.0", lo último que quiere es decir "¿cuál versión 1.0.0, la que le entregamos el lunes o la actualizada que le di el viernes? "

La actualización del tercer número está realmente diseñada para esto, la diferencia funcional entre 1.0.0 y 1.0.999 debería ser limitada, cuando agregue nuevas características grandes, luego actualice 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 justificar una actualización de 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 ha pasado la prueba y se ha aprobado. Luego actualizo ese valor y repito el movimiento entre el desarrollo y la prueba, incrementando el tercer número cada vez hasta que pase todo.

    
respondido por el gbjbaanb 30.01.2015 - 10:06
0

Ya se dieron buenas respuestas, pero también encontraría una manera de incorporar el git sha1 en su aplicación, de modo que puede encontrar que fue git commit 1b5619273127398123 que se usó 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 está funcionando bien, puede preguntar "¿Cuál es la larga fila de dígitos y letras en la segunda pantalla al hacer clic en Acerca de?", Y git checkout NNNNNN para obtenga exactamente esa versión, luego siga los mismos pasos que 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 por propósito evitas ese problema en particular).

Asegúrese también de que su sistema de compilación esté incluido en la versión, incluyendo preferiblemente la versión del compilador y demás, ya sea codificado o almacene las herramientas de compilación que usa cuando construye el producto dentro de su repositorio git.

    
respondido por el Mats Petersson 31.01.2015 - 00:33

Lea otras preguntas en las etiquetas