que - git commit

¿Cómo debo actualizar la versión dentro de mi pom.xml cuando libero usando git flow? (4)

En los proyectos de maven, la versión de un proyecto está contenida en <version> attritbute del archivo pom.xml. Al crear una nueva versión en el modelo de flujo de git, necesito marcar el número de versión. Este artículo explica cómo se hace esto (sin experto):

Crear una rama de lanzamiento
Cambia el número de versión y confirma.
Fusionar la rama de lanzamiento tanto para desarrollar como para dominar.

Además dice:

Es exactamente al comienzo de una versión de lanzamiento que a la próxima versión se le asigna un número de versión, no uno anterior. Hasta ese momento, la rama desarrollada reflejaba los cambios para la "próxima versión", pero no está claro si esa "próxima versión" eventualmente se convertirá en 0.3 o 1.0, hasta que se inicie la versión de la versión. Esa decisión se toma al inicio de la sucursal de lanzamiento y se lleva a cabo según las reglas del proyecto sobre el número de versión.

Veo dos problemas en conjunto con maven aquí:

La versión en desarrollo en maven sería [próxima versión] -SNAPSHOT. Por lo tanto, no podemos posponer realmente la decisión de cuál es la versión siguiente hasta el momento en que creamos una rama de lanzamiento. Por supuesto, si podemos cambiar de opinión más adelante, pero ya necesitamos ingresar / algún valor / aquí antes.
Antes de crear nuestro lanzamiento, la versión en el pom.xml era, digamos 1.1-SNAPSHOT . Ahora hemos cambiado eso a simplemente 1.1 en la rama de lanzamiento y lo hemos fusionado para dominarlo. Multa. Pero también deberíamos fusionar esa rama para desarrollarla y para eso necesitamos adaptar la versión a, por ejemplo, 1.2-SNAPSHOT . Y probablemente no deberíamos haber hecho eso en la rama de lanzamiento porque ese compromiso no debería ser parte del lanzamiento. En realidad, probablemente deberíamos haber hecho este cambio justo después de la bifurcación del desarrollo porque todos los compromisos futuros sobre el desarrollo serán para la próxima versión.

Cuando busqué en Google el problema, encontré algunos artículos sobre los complementos de Maven que pueden automatizar el proceso, lo que puede ser interesante, pero esta pregunta realmente es sobre cómo debería verse el gráfico git y dónde debería estar la versión de los bumps. automatiza esto utilizando un plugin de maven.

Con Maven, no debes cambiar el número de versión manualmente.

Debe agregar la información "scm" a su pom, para permitir que Maven se comprometa y empuje el cambio de versión directamente.

Luego, use el "plugin de liberación". Hará el trabajo por ti. Supongamos que su versión actual es "1.1-SNAPSHOT", la tarea de "release: perform" maven:

Cambie la versión a 1.1, confirme, etiquete esta versión y empújela.
Vuelva a cambiar la versión a 1.2-SNAPSHOT (o 1.1.1-SNAPSHOT, 2.0-SNAPSHOT ... puede elegir la próxima versión), confirme y presione.

Aquí hay un extracto de un historial de git en un proyecto donde se usa el complemento de lanzamiento de Maven:

* 2345678 - Normal developpement commit (on branch 1.2-SNAPHOT). * 5678901 - [maven-release-plugin] prepare for next development iteration * 8901234 - (tag: 1.1) [maven-release-plugin] prepare release 1.1 * 1234567 - Normal developpement commit (on branch 1.1-SNAPHOT).

Nota 1: En el momento del lanzamiento, debe proporcionar la próxima versión (1.2 en este ejemplo). Si cambias de opinión, puedes cambiarlo más tarde. El complemento Maven "version: set-version" le permite reasignar la versión de toda la jerarquía del proyecto. Solo tendrá que confirmar este cambio de versión antes de la próxima versión.

Nota 2: En el momento del lanzamiento, también puede cambiar la versión de lanzamiento. Incluso si la versión actual es 1.1-SNAPSHOT, puede decidir que la versión es la versión 2.0 y la próxima versión de desarrollo es la 2.1-SNAPSHOT.

Para las versiones normales, simplemente haga el bump de la versión de la instantánea después de fusionar la rama de la versión:

Crear la versión de lanzamiento a partir de develop y eliminar la instantánea de la versión
Fusionarlo en master
Fusionar en develop
Cambia la versión en develop a la siguiente versión de instantánea
Empuje tanto el master como el develop

A medida que presiona todos los cambios al mismo tiempo, el equipo solo verá aumentar la versión de la instantánea.

Para las revisiones, esto no es posible ya que lo creas a partir de la rama master . Hay una solución para este escenario, aquí hay un ejemplo que usa los comandos git en bruto.

Ejemplo: Tiene 1.0.0 en el master y desea crear una versión de la revisión 1.0.1 . Su desarrollo ya está en 1.1.0-SNAPSHOT .

git checkout master
git checkout -b hotfix/1.0.1
¡Haz tu hotfix!
mvn versions:set -DnewVersion=1.0.1
git commit -a -m "hotfix release 1.0.1"
git checkout master
git merge hotfix/1.0.1 (fácil, porque creamos la rama del master )
git checkout develop
mvn versions:set -DnewVersion=1.0.0
git commit -a -m "workaround to avoid merge conflicts"
git merge hotfix/1.0.1 (funcionará debido a la confirmación anterior)
mvn versions:set -DnewVersion=1.1.0-SNAPSHOT
git commit -a -m "set version back to 1.1.0-snapshot"

No es muy bonito pero funciona. Esta solución también es utilizada por jgitflow (un complemento de Maven para ayudarte con git flow)

Puede usar jgitflow-maven-plugin : goals jgitflow:release-start y jgitflow:release-finish .

Tenga en cuenta que Git fue desarrollado para el kernel de Linux que tiene sus propias reglas de versión.

Para Maven, debe crear una rama de lanzamiento que obtenga la versión instantánea del próximo lanzamiento. Este cambio debe ser un solo compromiso (es decir, solo el cambio del número de versión en pom.xml ). Al fusionar eso, extraiga el master y use git merge --strategy=ours <release-branch>

--strategy=ours significa: haga una fusión diciendo "todo en master se ha fusionado correctamente con la rama de lanzamiento"; no se están haciendo cambios para dominar. Posteriormente, Git tratará las sucursales como fusionadas (es decir, sin cambios) a pesar del número de versión diferente en ambas sucursales.

Para evitar todo tipo de problemas al crear master con Maven, use un número de versión impar o muy alto que nunca cambie como 99.DEV-SNAPSHOT .

Cuando realice el lanzamiento, -SNAPSHOT el -SNAPSHOT de la versión en la rama de lanzamiento y confirme. Posteriormente, verifica el master y se fusiona una vez más con --strategy=ours .