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

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

  1. Crear una twig de lanzamiento
  2. Cambiar el número de versión y confirmar
  3. Combina la twig de lanzamiento tanto para desarrollar como para dominar

Además dice:

Es exactamente al comienzo de una twig de publicación que a la próxima versión se le asigna un número de versión, no antes. Hasta ese momento, la twig de desarrollo 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 twig de la versión. Esa decisión se toma al inicio de la twig de publicación y se lleva a cabo según las reglas del proyecto sobre el número de versión.

Veo dos problemas en conjunción con maven aquí:

  1. La versión en desarrollo en maven sería [próxima versión] -SNAPSHOT. Por lo tanto, no podemos posponer la decisión sobre la versión que viene después hasta el momento en que creamos una twig de publicación. Por supuesto, si podemos cambiar de opinión más adelante, pero ya necesitamos ingresar / algún valor / aquí antes.
  2. 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 twig de lanzamiento y lo hemos combinado para dominar. Multa. Pero también deberíamos fusionar esa twig para desarrollarla y para eso tenemos que adaptar la versión a, por ejemplo, 1.2-SNAPSHOT . Y probablemente no deberíamos haber hecho eso en la twig de lanzamiento porque esa confirmación no debería ser parte del lanzamiento. De hecho, probablemente deberíamos haber hecho este cambio justo después de la bifurcación del desarrollo, porque todos los compromisos futuros en desarrollo serán para la próxima versión.

Cuando busqué en Google el problema, encontré algunos artículos sobre maven-plugins que pueden automatizar el process, que pueden ser interesantes, pero esta pregunta es realmente sobre cómo debería verse el gráfico de git y dónde debe estar el empujón de la versión y no cómo puedo automatizar esto usando un maven-plugin.

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

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

--strategy=ours significa: realizar una fusión diciendo "todo en el master se ha fusionado correctamente con la twig de lanzamiento"; no se están haciendo cambios al máster. Después, Git tratará las twigs como fusionadas (es decir, sin cambios) a pesar del diferente número de versión en ambas twigs.

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

Cuando realice la publicación, -SNAPSHOT la versión -SNAPSHOT de la versión en la twig de publicación y confirme. Posteriormente, --strategy=ours y se fusiona una vez más con --strategy=ours .

Para las versiones normales, solo haga la versión de instantánea después de fusionar la twig de versión:

  1. Cree la twig de publicación desactivada para develop y eliminar la instantánea de la versión
  2. Fusionarlo en master
  3. Fusionarlo en develop
  4. Cambie la versión en develop a la próxima versión de instantánea
  5. Empuja ambos master y develop

Al presionar todos los cambios al mismo time, el equipo solo verá boost la versión de la instantánea.

Para las revisiones, esto no es posible ya que lo crea fuera de la twig master . Hay una solución para este escenario, aquí hay un ejemplo usando los commands raw git.

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

  1. git checkout master
  2. git checkout -b hotfix/1.0.1
  3. ¡Haz tu revisión!
  4. mvn versions:set -DnewVersion=1.0.1
  5. git commit -a -m "hotfix release 1.0.1"
  6. git checkout master
  7. git merge hotfix/1.0.1 (fácil, porque creamos la twig de master )
  8. git checkout develop
  9. mvn versions:set -DnewVersion=1.0.0
  10. git commit -a -m "workaround to avoid merge conflicts"
  11. git merge hotfix/1.0.1 (funcionará debido a la confirmación anterior)
  12. mvn versions:set -DnewVersion=1.1.0-SNAPSHOT
  13. git commit -a -m "set version back to 1.1.0-snapshot"

No es muy lindo, pero funciona. Esta solución también es usada por jgitflow (un plugin de Maven para ayudarte con el flujo de git)

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

Debería agregar la información "scm" a su pom, para permitirle a Maven confirmar y presionar el cambio de versión directamente.

Luego, usa el "complemento de lanzamiento". Hará el trabajo por ti. Supongamos que su versión actual es "1.1-SNAPSHOT", la tarea maven "release: perform" hará lo siguiente:

  • Cambia la versión a 1.1, confirma, label esta versión y presiónala.
  • 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), comprométalo y empújelo.

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 aprovisionar la próxima versión (1.2 en este ejemplo). Si cambias de opinión, puedes cambiarla más tarde. El complemento "version: set-version" de Maven 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 2.0 y la siguiente versión de desarrollo sean 2.1-SNAPSHOT.

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