Question

I use Mercurial/TortoiseHg as my source control.

So far I have a single app and just about to finish the version 1.0. Once V 1.0 goes live, we already have features lined-up ready to be programmmed for the next version.

It is a phone app and right now V1.0 will be free but might want to make V2.0 paid and also later might make some minor bug/fixes updates to Free version.

I am not sure how the bug fixing will work while V2.0 is in progress.

My question is:

Do I need to fork or branch my repository from the point of V1.0 or I simply keep adding features to my current repository?
Whatever I need to do, I would also like to know why I need to do that.

Thanks.

Answer 1

I’d do the following:

Tag the revision that you release as v1.0

hg update -r <revision that's 1.0>
hg tag v1.0
hg ci -m 'Created V1.0 Tag'

Make a branch for any bug fixes that will go on top of that. This could be when you release V1.0, or when you have the first bug fix for it.

hg update v1.0 (or ideally the revision that added the V1.0 tag if it's immediately after V1.0)
hg branch release_v1
<Possibly do bug fix>
hg ci

Go back to the default branch to continue development of v2.

hg update default
<carry on working>

When you’ve got a bug-fix for v1

hg update release_v1
<do bug fix>

Then merge forward bug fixes from v1.x to v2.x

hg update default
hg merge release_v1
hg ci -m 'Merged V1 bug fixes into V2'

You create new tags as you do new releases. The release_v1 branch just keeps going, accumulating bug fixes, being merged into default (your development branch) when necessary. Just make sure you’re on the default branch when you merge as that determines which branch name the merge change-set has.

---

Editted to add that this is a variation on the stable/default work-flow that someone else mentioned, but I like to have a branch for each major release as then I can have more than one major release accepting bug fixes.