{"thread":{"id":"33420","subject":"Merge conflicts with version numbers in release branches","startedAt":"2013-04-07T15:49:10Z","lastAt":"2013-05-29T09:09:08Z","messageCount":2,"participants":["Thomas Koch","Enrico Weigelt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"213415","messageId":"201304071749.10912.thomas@koch.ro","threadId":"33420","inReplyTo":null,"subject":"Merge conflicts with version numbers in release branches","fromName":"Thomas Koch","fromEmail":"thomas@koch.ro","sentAt":"2013-04-07T15:49:10Z","receivedAt":"2013-04-07T15:49:10Z","isPatch":false,"sender":{"key":"thomas@koch.ro","avatar":null},"body":"Hi,\n\nit's a common problem[1,2,3] in Maven (Java) projects and probably in other \nenvironments too: You have the version number of your project written in the \npom.xml. When one merges changes upwards from the maint branche to master, the \nversion numbers in maint and master are different and cause a merge conflict.\n\nYou might think of solutions for easy cases, but think about several releases \nfrom the maint branches and several major releases in the same time frame and \nyou will run into merge conflicts.\n\nStill, do you know any best practice how to deal with these? Do you know \nexamples from other language environments that also keep the version numbers \nunder version control and suffer from the same problem? Or is the version \nnumber somehow taken from the git tag in your environment?\n\n[1] http://brettporter.wordpress.com/2012/02/02/automatically-resolving-\nversion-conflicts-in-maven-poms-when-merging/\n[2] http://bxm-dev.blogspot.ch/2012/05/gitflow-and-maven.html\n[3] http://stackoverflow.com/questions/3555160/merging-changes-from-a-maven-\nrelase-branch-yields-conflicts-due-to-changed-versi\n\nThank you,\n\nThomas Koch, http://www.koch.ro\n"},{"id":"218792","messageId":"1346886189.4154.1369818548437.JavaMail.root@vnc.biz","threadId":"33420","inReplyTo":"201304071749.10912.thomas@koch.ro","subject":"Re: Merge conflicts with version numbers in release branches","fromName":"Enrico Weigelt","fromEmail":"enrico.weigelt@vnc.biz","sentAt":"2013-05-29T09:09:08Z","receivedAt":"2013-05-29T09:09:08Z","isPatch":false,"sender":{"key":"enrico.weigelt@vnc.biz","avatar":"https://gravatar.com/avatar/15479654ea5be5109582e0713a8ab4bb258846099c516dd320dc686ef70a8a3e?d=mp&s=160"},"body":"Thomas Koch wrote:\n\n> it's a common problem[1,2,3] in Maven (Java) projects and probably in other\n> environments too: You have the version number of your project written in the\n> pom.xml. When one merges changes upwards from the maint branche to master,\n> the\n> version numbers in maint and master are different and cause a merge conflict.\n\nMy advice: dont merge directly, but rebase to latest master. Maybe even rebase\nincrementally (eg. \"git rebase master~100 && git rebase master~99 && ...).\nThis heavily reduces the chance of conflicts that need to be resolved manually.\n\nI'm a big fan of topic branches. For example, we have some bug #1234 in\nthe maintenance release. Fork off at latest maint, lets call the branch\n1234_somewhat. Now do your bugfixing, testing, etc. When thats done, rebase\non latest maint (in case maint moved further) and merge it into maint.\nNow rebase the 1234_somewhat branch onto master, do tests etc and finally\nmerge into it. (note: all merges here will be fast-forward, IOW: pure \nappend operations).\n\nOf course, all of this wont make the conflicts on the version number change\ngo away magically, but at least it will be more clear while resolving it.\nIf you always do the version number changes in some separate commit, which\nhas some specially formatted message (eg. 'Release: 1.2.4') you could \nhack some some little filter-branch magic, which automatically kicks off\nthese commits before rebasing.\n"}]}