Merge conflicts with version numbers in release branches

Merge conflicts with version numbers in release branches

[Thomas Koch]

Hi,

it's a common problem[1,2,3] in Maven (Java) projects and probably in other 
environments too: You have the version number of your project written in the 
pom.xml. When one merges changes upwards from the maint branche to master, the 
version numbers in maint and master are different and cause a merge conflict.

You might think of solutions for easy cases, but think about several releases 
from the maint branches and several major releases in the same time frame and 
you will run into merge conflicts.

Still, do you know any best practice how to deal with these? Do you know 
examples from other language environments that also keep the version numbers 
under version control and suffer from the same problem? Or is the version 
number somehow taken from the git tag in your environment?

[1] http://brettporter.wordpress.com/2012/02/02/automatically-resolving-
version-conflicts-in-maven-poms-when-merging/
[2] http://bxm-dev.blogspot.ch/2012/05/gitflow-and-maven.html
[3] http://stackoverflow.com/questions/3555160/merging-changes-from-a-maven-
relase-branch-yields-conflicts-due-to-changed-versi

Thank you,

Thomas Koch, http://www.koch.ro

Re: Merge conflicts with version numbers in release branches

[Enrico Weigelt]

Thomas Koch wrote:

> it's a common problem[1,2,3] in Maven (Java) projects and probably in other
> environments too: You have the version number of your project written in the
> pom.xml. When one merges changes upwards from the maint branche to master,
> the
> version numbers in maint and master are different and cause a merge conflict.

My advice: dont merge directly, but rebase to latest master. Maybe even rebase
incrementally (eg. "git rebase master~100 && git rebase master~99 && ...).
This heavily reduces the chance of conflicts that need to be resolved manually.

I'm a big fan of topic branches. For example, we have some bug #1234 in
the maintenance release. Fork off at latest maint, lets call the branch
1234_somewhat. Now do your bugfixing, testing, etc. When thats done, rebase
on latest maint (in case maint moved further) and merge it into maint.
Now rebase the 1234_somewhat branch onto master, do tests etc and finally
merge into it. (note: all merges here will be fast-forward, IOW: pure 
append operations).

Of course, all of this wont make the conflicts on the version number change
go away magically, but at least it will be more clear while resolving it.
If you always do the version number changes in some separate commit, which
has some specially formatted message (eg. 'Release: 1.2.4') you could 
hack some some little filter-branch magic, which automatically kicks off
these commits before rebasing.