Release management in Mercurial - [major].[minor].[bugfix] versioning with supporting older major versions

Question

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.

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

Answer 2

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.