1

I have been exploring different answers about release management in Mercurial and almost found the right way of doing it. However, I just need a bit of help to get it right so that everything clicks nicely in my head.

Here is what our company needs:

1) Will be using versioning scheme {major.minor.patch} for development

2) Named branches and tags will be used for managing releases (as opposed to cloning repositories for example)

3) While working on release 3.0 we might need to support older major releases. For example if a bug is found in release 2.1 we will need to fix it (in release 2.1.1) and merge all the way back to the current release 3.0

Having researched different options and answers, the following great answer from Steve Losh (just copied the changeset tree below) is probably what we need but I can't get how you can work on 2.1.1 and merge all the way back to 3.0 in default if the latter has already been tagged? 

$ hg glog -l 1000    
@       changeset:  25:efc0096f47c0  tip
|       summary:    Added tag 3.0 for changeset d1a7fc3d7d77
|
o       changeset:  24:d1a7fc3d7d77  3.0
|\      summary:    Merge in the redesign changes.
| |
| o     changeset:  23:b5b69d24c8f7 3.0-dev
| |     summary:    Finish 3.0 redesign.
| |
| o     changeset:  22:4c2f98fac54b 3.0-dev
|/|     summary:    Merge in the latest changes to 2.1/mainline.
| |
o |     changeset:  21:37df04521032
| |     summary:    Added tag 2.1 for changeset 39ecc520fc0a
| |
o |     changeset:  20:39ecc520fc0a  2.1
|\ \    summary:    2.1 development is done.
| | |
| o |   changeset:  19:208f3f9236af 2.1-dev
| | |   summary:    Finish the 2.1 work.
| | |
| | o   changeset:  18:4a024009a9d6 3.0-dev
| | |   summary:    More redesign work.
| | |
| | o   changeset:  17:00c416888c25 3.0-dev
| |/|   summary:    Merge in changes from the 2.1 branch to keep the redesign current.
| | |
| o |   changeset:  16:a57e781a0db1 2.1-dev
| | |   summary:    More 2.1 work.
| | |
| | o   changeset:  15:ddeb65402a61 3.0-dev
| | |   summary:    More redesign work.
| | |
+---o   changeset:  14:90f5d7a8af9a 3.0-dev
| | |   summary:    Merge in the fire fixes.
| | |
| o |   changeset:  13:78a949b67bb9 2.1-dev
|/| |   summary:    Merge in the fire fixes.
| | |
o | |   changeset:  12:6dfe9d856202
| | |   summary:    Oh no everything is on fire, fix it in the mainline.
| | |
| o |   changeset:  11:86767671dcdb 2.1-dev
| | |   summary:    Smaller changes for 2.1.
| | |
| | o   changeset:  10:25dec81d2546 3.0-dev
| | |   summary:    Work more on the redesign.
| | |
+---o   changeset:  9:42c7d689fb24 3.0-dev
| |     summary:    Start working on a complete redesign.
| |
| o     changeset:  8:3da99186ca7d 2.1-dev
|/      summary:    Start working on 2.1.
|
o       changeset:  7:9ba79361827d
|       summary:    Added tag 2.0 for changeset 755ed5c5e291
|
o       changeset:  6:755ed5c5e291  2.0
|\      summary:    Merge in the dev branch for 2.0.
| |
| o     changeset:  5:44a833fcc838 2.0-dev
| |     summary:    Finish work on 2.0.
| |
| o     changeset:  4:d7ba6aae1651 2.0-dev
|/|     summary:    Merge in the critical fix.
| |
o |     changeset:  3:968049f1b33a
| |     summary:    Fix a critical bug on the main branch.
| |
| o     changeset:  2:917869609b25 2.0-dev
| |     summary:    More work on the new version.
| |
| o     changeset:  1:f95798b9cb2e 2.0-dev
|/      summary:    Start working on version 2.0.
|
o       changeset:  0:8a3fb044d3f4
        summary:    Initial commit.

In other words, with the above changeset tree/releases, is it possible to work on 2.1.1 fix while we already started working on 3.0? I mean how would we merge 2.1.1 back into default if the 3.0 has been tagged already? Am I missing something here? if not, is there a more suitable way for us to manage releases as per our requirments? It would be great if you could provide a similar snapshot of the changeset tree for the scenario.

Thanks very much in advance. You guys rock.

Community
  • 1
  • 1
passionateDeveloper
  • 13
  • 3

2 Answers2

1

Based upon your requirement to maintain multiple release versions, I would consider a different branching strategy which uses the default branch for development and has a branch for each major version. This is described on this page - it also has a section on what to do about big fixes.

I've worked an example similar to the one above:

@    changeset:   13:3d6ac57cce61
|\   tag:         tip
| |  parent:      9:5953138c3f87
| |  parent:      12:9691c48d79f2
| |  user:        steve.kaye
| |  date:        Tue Jun 26 08:39:42 2012 +0100
| |  summary:     Merge bug fix
| |
| o  changeset:   12:9691c48d79f2
| |  branch:      V3
| |  user:        steve.kaye
| |  date:        Tue Jun 26 08:35:23 2012 +0100
| |  summary:     Added tag 3.1 for changeset e49d9a6bb459
| |
| o    changeset:   11:e49d9a6bb459
| |\   branch:      V3
| | |  tag:         3.1
| | |  parent:      7:5354c406c68a
| | |  parent:      8:00dfa7869e8c
| | |  user:        steve.kaye
| | |  date:        Tue Jun 26 08:35:20 2012 +0100
| | |  summary:     Merge bug fix
| | |
| | | o  changeset:   10:a84c532ce507
| | |/   branch:      V2
| | |    parent:      8:00dfa7869e8c
| | |    user:        steve.kaye
| | |    date:        Tue Jun 26 08:31:09 2012 +0100
| | |    summary:     Added tag 2.1 for changeset 00dfa7869e8c
| | |
o | |  changeset:   9:5953138c3f87
| | |  parent:      5:80b80eb9581b
| | |  user:        steve.kaye
| | |  date:        Tue Jun 26 08:30:41 2012 +0100
| | |  summary:     Start work on next version
| | |
| | o  changeset:   8:00dfa7869e8c
| | |  branch:      V2
| | |  tag:         2.1
| | |  parent:      4:6c4a68f3c073
| | |  user:        steve.kaye
| | |  date:        Tue Jun 26 08:29:56 2012 +0100
| | |  summary:     Fixed a bug in V2
| | |
| o |  changeset:   7:5354c406c68a
| | |  branch:      V3
| | |  user:        steve.kaye
| | |  date:        Tue Jun 26 08:24:52 2012 +0100
| | |  summary:     Added tag 3.0 for changeset 3f3a006aacdd
| | |
| o |  changeset:   6:3f3a006aacdd
|/ /   branch:      V3
| |    tag:         3.0
| |    user:        steve.kaye
| |    date:        Tue Jun 26 08:23:54 2012 +0100
| |    summary:     Version 3.0 ready for release
| |
o |  changeset:   5:80b80eb9581b
| |  parent:      2:21cf96f3ed91
| |  user:        steve.kaye
| |  date:        Tue Jun 26 08:22:47 2012 +0100
| |  summary:     Start work on next version
| |
| o  changeset:   4:6c4a68f3c073
| |  branch:      V2
| |  user:        steve.kaye
| |  date:        Tue Jun 26 08:20:07 2012 +0100
| |  summary:     Added tag 2.0 for changeset 666cc4453281
| |
| o  changeset:   3:666cc4453281
|/   branch:      V2
|    tag:         2.0
|    user:        steve.kaye
|    date:        Tue Jun 26 08:19:43 2012 +0100
|    summary:     Version 2.0 ready for release
|
o  changeset:   2:21cf96f3ed91
|  user:        steve.kaye
|  date:        Tue Jun 26 08:18:31 2012 +0100
|  summary:     More work on the new version
|
o  changeset:   1:6177b193da7c
|  user:        steve.kaye
|  date:        Tue Jun 26 08:18:06 2012 +0100
|  summary:     Start work on version 2.0
|
o  changeset:   0:51cc3c0590f9
   user:        steve.kaye
   date:        Tue Jun 26 08:17:27 2012 +0100
   summary:     Initial commit

As you can see, I have three branches. default is where the new development was done then I decided that it was ready for release so I created a V2 branch and tagged it 2.0. I then continued work on default until I decided that it was ready for release when I branched to V3 and tagged it as 3.0. I then discovered a bug and found that it was introduced in version 2 so I fixed it on the V2 branch and tagged it 2.1. I then merged that fix into V3 and tagged it 3.1 and then merged V3 to default to get the fix in the development code.

It is easier to port the fixes between branches if you start in the oldest version. This allows you to merge that fix to the newer branches more easily. If you were to fix it in default first, you couldn't merge that fix to V2 or V3 because you'd get all the new features in the older versions as well as the bug fix.

Notice that you still have as many heads as the other branching strategy - one default one for V2 and one for V3 but they will be arranged more neatly if you are maintaining multiple releases. To get the latest release of version 2 of your software you just need to do hg up V2 whereas before you'd need to find out what the latest version 2 is and then update to that.

Steve Kaye
  • 6,262
  • 2
  • 23
  • 27
  • Thanks very much for your fantastic help Steve. You rock. – passionateDeveloper Jun 26 '12 at 23:13
  • I'm working on a Ruby script to automate this: https://gist.github.com/rcook/6064683. Note, that this assumes that releases branches are named "v.", though it could easily be modified to work with other naming conventions. – Richard Cook Jul 23 '13 at 18:06
0

The second paragraph of your linked question says:

Once you're done with 2.0, merge 2.0-dev into default and tag the result as 2.0.

From this, I think that the idea is that you wouldn't tag 3.0 until you are ready to release it. If you have released it, then the fix for 2.1.1 wouldn't go into 3.0, it would go into 3.0.1 and you wouldn't have a problem with your workflow.

Also, you can move tags so if you do find that you tagged 3.0 too early you can move it using the -f flag to hg tag.

Steve Kaye
  • 6,262
  • 2
  • 23
  • 27
  • Thanks for your answer. I can see how you can merge a bug fix from previous release into your current release. But what about this scenario: bug fix is 1.1.1 and current release tagged in default as 5.7. How do we make sure that this bug is fixed in all releases in between 1 and 5: release 2.x 3.x and 4.x? thanks – passionateDeveloper Jun 24 '12 at 22:57
  • Assuming that the 1.1.1 branch doesn't include anything that you don't want in the other branches: you could branch at 2.x, merge in 1.1.1 and tag. You'd then do the same for 3.x and 4.x. If it does include changes you don't want you'd do the same but `hg graft` the changes instead of merging. – Steve Kaye Jun 25 '12 at 09:02
  • Thanks a lot Steve, your help is invaluable. Please correct me if I am wrong, but it looks to me that with this approach you will never be able to close the branches 2.x 3.x and 4.x because its too late to merge them back to default? Is my understanding correct? Will will have multiple heads with this approach for all major release branches? If so, maybe the whole workflow is incorrect and we need to change it? – passionateDeveloper Jun 25 '12 at 23:23
  • I don't think that the workflow looks good for a system that maintains multiple live releases because you only use one branch for releasing so `3.0` effectively supersedes `2.1`. It works but it would get messy and could end up being too difficult to track which version is the latest of release 2. I'd have `default` as development and a branch per public version and tag that when you release. You'd still have as many heads but each head would be a named branch so it would be easier to track. – Steve Kaye Jun 26 '12 at 07:15
  • I've added another answer with a different branching strategy. – Steve Kaye Jun 26 '12 at 07:55