I suggest using option 3. This also what the standard branching wiki page suggests. Your history will then look like this after having merged a couple of fixes from RC1 into default:
default: ... a -- b -- c -- d -- e -- f -- g
\ / /
RC1: x --- y ------ z --- w
By merging like that, there's no chance of forgetting to include a bugfix from RC1 — you're letting the tool keep track of things instead of having to remember it yourself.
The problem you mention about the version in the pom.xml
file being updated incorrectly is due to you updating the version after you created the RC1 branch. In other words, you updated it in x
or y
above.
Instead, I would change the version from 1.0-SNAPSHOT
to 1.0
on the default branch before branching off. After you make the branch, you change the version to 2.0-SNAPSHOT
or whatever your next version will be. Annotating the above graph with version numbers, it will look like this:
1.0-S 1.0 2.0-S 2.0-S 2.0-S 2.0-S 2.0-S
default: ... a ---- b ---- c ---- d ---- e ---- f ---- g
\ / /
RC1: x ------- y -------- z ------- w
1.0 1.0 1.0 1.0
Remember, that when Mercurial is merging a file, it compares exactly three versions of the file:
- the ancestor version
- the local version (the version in the working copy parent revision)
- the other version (the version you are merging into the current branch)
So when you merge y
into c
above, these three versions of your pom.xml
will be considered:
- the version from
b
with version 1.0 - the version from
c
with version 2.0-SNAPSHOT - the version from
y
with version 1.0
A three-way merge is really a kind of "vote" between the three files: the file in c
says the version should be changed to 2.0-SNAPSHOT. The file from y
says the version can be kept at 1.0. Changes are always considered good by a three-way merge, so the merge result will be version 2.0-SNAPSHOT.