aleksandr-m / gitflow-maven-plugin

The Git-Flow Maven Plugin supports various Git workflows, including GitFlow and GitHub Flow. This plugin runs Git and Maven commands from the command line.
https://aleksandr-m.github.io/gitflow-maven-plugin/
Apache License 2.0
490 stars 182 forks source link

Question: How to release from support branch? #269

Closed glianeric closed 2 years ago

glianeric commented 3 years ago

Here's the problem I am facing:

Release-start will check out the production branch to begin from there. Release-finish will try to merge the changes to the production branch.

Looking at the code, it appears that these two mojos do not deal with support branches at all. I do not wish to run hotfixes from support branches at all; in our workflow the support branch is to be directly worked on and released, a bit unlike the production branch which requires hotfixes and feature branches etc.

Would this be something that could be added to the release-* mojos, or would a support-release mojo be more appropriate here?

Or am I missing something?

aleksandr-m commented 3 years ago

Do you merge from support branches into master or develop?

glianeric commented 3 years ago

Hello and thank You for the reply ... also, Happy New Year :)

No, there will be no such merging for me. The support branch will live on its own and it will not go back to dev/support in an automated way. If necessary, changes will be cherry picked from/into develop as required. I do not wish to start hotfixes from these branches - on release the versions will be changes appropriately (by default we will use digittoincrement=2), tagged, etc. like a regular release, but without merging.

To give you a little deeper background on my process: I want to create the support branches for the specific product version once, then make changes and release as necessary. This helps me avoid the hotfix process which would have me creating multiple branches on demand, and this is also semantically more clear since the developers can easily see that the branches are for product version X. These branches would be manually deleted when all the customers are moved to newer product versions.

So in my case if I have say 5 repos (I have a lot more, but for example's sake) like: api, core libs, domain libs, customer libs and finally applications and packages - on all of them I would create a branch called something like support/4.3 (this would be the 'product' version number, not the version in the repo's POMs).

beatngu13 commented 2 years ago

I also wonder what is the "Git-Flow Maven Plugin"-way of releasing from a support branch (without merging the branch anywhere)?

Context: We would like to use support branch for fixes for old releases. Currently, we start a support branch via the Git-Flow Maven Plugin, but use the Maven Release Plugin for tagging and versioning (which feels odd).

aleksandr-m commented 2 years ago

@beatngu13 What is releasing then? Bumping the version?

beatngu13 commented 2 years ago

@aleksandr-m bumping the version and tagging the corresponding commit.

Meanwhile, we do the following:

  1. gitflow:support-start with tagName pointing to the old release
  2. gitflow:hotfix-start with fromBranch referencing the support branch
  3. gitflow:hotfix-finish with skipMergeDevBranch
aleksandr-m commented 2 years ago

So separate goal to bump version in support and add tag. Thanks for response, I'll think about that.

aleksandr-m commented 2 years ago

@glianeric @beatngu13 See new version-update goal.

aleksandr-m commented 2 years ago

Released in 1.18.0.