Gestión de lanzamientos en versiones de Mercurial – . . con soporte de versiones mayores anteriores

He estado explorando diferentes respuestas sobre la gestión de lanzamientos en Mercurial y casi he encontrado la forma correcta de hacerlo. Sin embargo, solo necesito un poco de ayuda para hacerlo bien para que todo encaje bien en mi cabeza.

Esto es lo que nuestra empresa necesita:

1) Utilizará el esquema de versiones {major.minor.patch} para el desarrollo

2) Las twigs y tags con nombre se utilizarán para administrar las versiones (a diferencia de los repositorys de clonación, por ejemplo)

3) Al trabajar en la versión 3.0, es posible que necesitemos respaldar lanzamientos mayores más antiguos. Por ejemplo, si se encuentra un error en la versión 2.1, tendremos que arreglarlo (en la versión 2.1.1) y fusionar todo el path de return a la versión actual 3.0

Después de haber investigado diferentes opciones y respuestas, la siguiente gran respuesta de Steve Losh (simplemente copié el tree de cambios a continuación) es probablemente lo que necesitamos, pero no entiendo cómo puedes trabajar en 2.1.1 y fusionar todo el path de return a 3.0 en pnetworkingeterminado si este último ya ha sido labeldo?

$ hg glog -l 1000 @ changeset: 25:efc0096f47c0 tip | summary: Added tag 3.0 for changeset d1a7fc3d7d77 | o changeset: 24:d1a7fc3d7d77 3.0 |\ summary: Merge in the networkingesign changes. | | | o changeset: 23:b5b69d24c8f7 3.0-dev | | summary: Finish 3.0 networkingesign. | | | o changeset: 22:4c2f98fac54b 3.0-dev |/| summary: Merge in the latest changes to 2.1/mainline. | | o | changeset: 21:37df04521032 | | summary: Added tag 2.1 for changeset 39ecc520fc0a | | o | changeset: 20:39ecc520fc0a 2.1 |\ \ summary: 2.1 development is done. | | | | o | changeset: 19:208f3f9236af 2.1-dev | | | summary: Finish the 2.1 work. | | | | | o changeset: 18:4a024009a9d6 3.0-dev | | | summary: More networkingesign work. | | | | | o changeset: 17:00c416888c25 3.0-dev | |/| summary: Merge in changes from the 2.1 branch to keep the networkingesign current. | | | | o | changeset: 16:a57e781a0db1 2.1-dev | | | summary: More 2.1 work. | | | | | o changeset: 15:ddeb65402a61 3.0-dev | | | summary: More networkingesign work. | | | +---o changeset: 14:90f5d7a8af9a 3.0-dev | | | summary: Merge in the fire fixes. | | | | o | changeset: 13:78a949b67bb9 2.1-dev |/| | summary: Merge in the fire fixes. | | | o | | changeset: 12:6dfe9d856202 | | | summary: Oh no everything is on fire, fix it in the mainline. | | | | o | changeset: 11:86767671dcdb 2.1-dev | | | summary: Smaller changes for 2.1. | | | | | o changeset: 10:25dec81d2546 3.0-dev | | | summary: Work more on the networkingesign. | | | +---o changeset: 9:42c7d689fb24 3.0-dev | | summary: Start working on a complete networkingesign. | | | o changeset: 8:3da99186ca7d 2.1-dev |/ summary: Start working on 2.1. | o changeset: 7:9ba79361827d | summary: Added tag 2.0 for changeset 755ed5c5e291 | o changeset: 6:755ed5c5e291 2.0 |\ summary: Merge in the dev branch for 2.0. | | | o changeset: 5:44a833fcc838 2.0-dev | | summary: Finish work on 2.0. | | | o changeset: 4:d7ba6aae1651 2.0-dev |/| summary: Merge in the critical fix. | | o | changeset: 3:968049f1b33a | | summary: Fix a critical bug on the main branch. | | | o changeset: 2:917869609b25 2.0-dev | | summary: More work on the new version. | | | o changeset: 1:f95798b9cb2e 2.0-dev |/ summary: Start working on version 2.0. | o changeset: 0:8a3fb044d3f4 summary: Initial commit. 

En otras palabras, con el tree / releases del set de cambios anterior, ¿es posible trabajar con la corrección 2.1.1 mientras ya comenzamos a trabajar en 3.0? Quiero decir, ¿cómo fusionaríamos 2.1.1 de nuevo en el valor pnetworkingeterminado si ya se ha labeldo el 3.0? ¿Me estoy perdiendo de algo? si no, ¿hay una forma más adecuada para que administremos las entregas según nuestros requisitos? Sería genial si pudiera proporcionar una instantánea similar del tree del set de cambios para el escenario.

Muchas gracias de antemano. Ustedes molan.

En function de su requisito de mantener versiones de lanzamiento múltiples, consideraría una estrategia de bifurcación diferente que utiliza la twig default para el desarrollo y tiene una twig para cada versión principal. Esto se describe en esta página ; también tiene una sección sobre qué hacer con las soluciones grandes.

He trabajado un ejemplo similar al anterior:

 @ changeset: 13:3d6ac57cce61 |\ tag: tip | | parent: 9:5953138c3f87 | | parent: 12:9691c48d79f2 | | user: steve.kaye | | date: Tue Jun 26 08:39:42 2012 +0100 | | summary: Merge bug fix | | | o changeset: 12:9691c48d79f2 | | branch: V3 | | user: steve.kaye | | date: Tue Jun 26 08:35:23 2012 +0100 | | summary: Added tag 3.1 for changeset e49d9a6bb459 | | | o changeset: 11:e49d9a6bb459 | |\ branch: V3 | | | tag: 3.1 | | | parent: 7:5354c406c68a | | | parent: 8:00dfa7869e8c | | | user: steve.kaye | | | date: Tue Jun 26 08:35:20 2012 +0100 | | | summary: Merge bug fix | | | | | | o changeset: 10:a84c532ce507 | | |/ branch: V2 | | | parent: 8:00dfa7869e8c | | | user: steve.kaye | | | date: Tue Jun 26 08:31:09 2012 +0100 | | | summary: Added tag 2.1 for changeset 00dfa7869e8c | | | o | | changeset: 9:5953138c3f87 | | | parent: 5:80b80eb9581b | | | user: steve.kaye | | | date: Tue Jun 26 08:30:41 2012 +0100 | | | summary: Start work on next version | | | | | o changeset: 8:00dfa7869e8c | | | branch: V2 | | | tag: 2.1 | | | parent: 4:6c4a68f3c073 | | | user: steve.kaye | | | date: Tue Jun 26 08:29:56 2012 +0100 | | | summary: Fixed a bug in V2 | | | | o | changeset: 7:5354c406c68a | | | branch: V3 | | | user: steve.kaye | | | date: Tue Jun 26 08:24:52 2012 +0100 | | | summary: Added tag 3.0 for changeset 3f3a006aacdd | | | | o | changeset: 6:3f3a006aacdd |/ / branch: V3 | | tag: 3.0 | | user: steve.kaye | | date: Tue Jun 26 08:23:54 2012 +0100 | | summary: Version 3.0 ready for release | | o | changeset: 5:80b80eb9581b | | parent: 2:21cf96f3ed91 | | user: steve.kaye | | date: Tue Jun 26 08:22:47 2012 +0100 | | summary: Start work on next version | | | o changeset: 4:6c4a68f3c073 | | branch: V2 | | user: steve.kaye | | date: Tue Jun 26 08:20:07 2012 +0100 | | summary: Added tag 2.0 for changeset 666cc4453281 | | | o changeset: 3:666cc4453281 |/ branch: V2 | tag: 2.0 | user: steve.kaye | date: Tue Jun 26 08:19:43 2012 +0100 | summary: Version 2.0 ready for release | o changeset: 2:21cf96f3ed91 | user: steve.kaye | date: Tue Jun 26 08:18:31 2012 +0100 | summary: More work on the new version | o changeset: 1:6177b193da7c | user: steve.kaye | date: Tue Jun 26 08:18:06 2012 +0100 | summary: Start work on version 2.0 | o changeset: 0:51cc3c0590f9 user: steve.kaye date: Tue Jun 26 08:17:27 2012 +0100 summary: Initial commit 

Como puedes ver, tengo tres twigs. default es donde se realizó el nuevo desarrollo, entonces decidí que estaba listo para su lanzamiento, así que creé una twig V2 y la etiqueté como 2.0 . Luego continué trabajando en el default hasta que decidí que estaba listo para ser lanzado cuando me bifurqué a V3 y lo etiqueté como 3.0 . Luego descubrí un error y descubrí que se introdujo en la versión 2, así que lo arreglé en la twig V2 y lo etiqueté con 2.1 . Luego fusioné esa corrección en V3 y la etiqueté 3.1 y luego fusioné V3 a la default para get la corrección en el código de desarrollo.

Es más fácil portar las correcciones entre sucursales si comienza en la versión más antigua. Esto le permite fusionar esa solución a las twigs más nuevas más fácilmente. Si fueras a solucionarlo primero en default , no podrías combinar esa corrección con V2 o V3 porque obtendrías todas las características nuevas en las versiones anteriores, así como la corrección de errores.

Tenga en count que todavía tiene tantas cabezas como la otra estrategia de bifurcación, una default para V2 y otra para V3 pero se organizarán de forma más orderada si mantiene varias versiones. Para get la versión más reciente de la versión 2 de su software, solo tiene que hacer hg up V2 mientras que antes tendría que averiguar cuál es la última versión 2 y luego actualizarla.

El segundo párrafo de su pregunta vinculada dice:

Una vez que haya terminado con 2.0, fusione 2.0-dev en el valor pnetworkingeterminado y marque el resultado como 2.0.

A partir de esto, creo que la idea es que no labelr 3.0 hasta que esté listo para lanzarlo. Si lo ha lanzado, la solución para 2.1.1 no entraría en 3.0 , entraría en 3.0.1 y no tendría problemas con su flujo de trabajo.

Además, puede mover tags, de modo que si encuentra que marcó 3.0 demasiado pronto, puede moverlo usando la hg tag -f para hg tag .