Merge conflicts with version numbers in release branches

Thomas Koch· Apr 7, 2013, 15:49 UTC · lore

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

Enrico Weigelt· May 29, 2013, 09:09 UTC · re: Thomas Koch · lore

Re: Merge conflicts with version numbers in release branches

Thomas Koch wrote:

Show 5 quoted lines

> 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.