Versiones semánticas y git branches

Tengo una twig principal (v1.0) y una twig de desarrollo (v1.1dev). Hago una nueva twig de lanzamiento desde dev, supero el número de versión de v1.1dev a v1.1, termino, fusiono dicha twig de release en master, y prest – v1.1 nace.

Pero luego fusiono la misma twig de liberación en dev y la twig dev también es v1.1. Aunque técnicamente cierto, siento que siempre debe terminar en dev porque después de todo, siempre es la versión de desarrollo la que está funcionando para la siguiente versión real

Así que mi pregunta es si todos dedican una única confirmación en la twig de desarrollo para encontrar la versión de su código de diciembre después de fusionarse en una twig de lanzamiento o si hay algo que me falta (un script, una metodología, una técnica, etc.) ? ¿La descripción anterior es generalmente representativa de cómo las personas superan sus numbers de versión?

TL; DR: ¿ Cuándo se deben encontrar los numbers de versión en las diversas twigs de un proyecto versionado por git, asumiendo el control de versiones semánticas?

Aunque probablemente ya no sea un problema para usted ahora, tiene razón cuando dice:

… siempre es la versión de desarrollo que está trabajando hacia la próxima versión real …

Cuando ramifique su código, abandone la versión de la sucursal en v1.0. Esta será la twig de publicación, la base de código que se incluye en esta versión, que corregirá si alguna vez tiene que corregir errores o mejorar esta versión en el futuro si los usuarios no pueden actualizar a la siguiente versión completa.

Siempre puede fusionar los cambios de esa twig de nuevo en maestro, pero obviamente no cualquier código que defina el número de versión, que normalmente se encuentra en una configuration, propiedad o file de compilation de todos modos.

Después de la bifurcación, cambie la versión en el maestro a v1.1.x o v1.1-DEV o lo que sea que quiera llamar.

    Intereting Posts