Going between development & production in Mercuria

Question

I've used mercurial for some time now, but haven't really gotten used to working with branches, so I am struggling to figure out whether this workflow makes sense or not before applying it to a real project.

The question:
Does it really make sense to resurrect a development branch every time we're going to work on a new release by merging production into it, or should we instead make unique named short-lived development branches like development-1.1?

Description of workflow:
Every production-ready revision of our code will be tagged (1.0,1.1 and so on) and placed in the production branch. As soon as we've put 1.0 into production, we immediately start working on next release - 1.1, by opening a branch named development, which is then sub-branched by every developer for every assigned feature to keep things neat. Very straightforward this far.

The development branch, now containing the in-merged feature branch, is then tested and merged back into production as the changes have been considered production-ready.

When when we need to continue working on an upcoming release, 1.2 in this example, we merge the production-branch into the development one and start working.

Illustrated history of the revisions:

@    changeset:   8:21e89b501d4e
|\   branch:      development
| |  tag:         tip
| |  description: Development stage for v1.2 opened by merging production into development.
| |
| o  changeset:   7:920ca77aa956
|/|  branch:      production
| |  tag:         1.1
| |  description: Version 1.1 stable (merged from development).
| |
o |    changeset:   6:691b7aa99e42
|\ \   branch:      development
| | |  description: Feature merged in to development
| | |
| o |  changeset:     5:5156cb9cf556
| | |  branch:        feature
| | |  description:   Feature finished
| | |
| o |  changeset:     4:0345dc73e144
|/ /   branch:        feature
| |    description:   Work started on a feature
| |
o |  changeset:    3:9d49be5d8a03
|/   branch:       development
|    description:  Development branch opened
|
o  changeset:     2:ba818420fa88
|  branch:        production
|  tag:           1.0
|  description:   Version 1.0 stable. Woop woop!

Answer 1

With Mercurial named branches are forever, and thus the general advice is to only use them for names that always apply. Things like "stable" and "development", not things like "bug-194534" and "release-1.1". This is explained nicely in the wiki.

For things that have finite lifespans you're better off using something like bookmarks which are much closer to what git calls branches than are Mercurial named branches. Other great options for short-lived concepts are anonymous branches or clones, both of which are non-permanent.

The general advice is to use default as your development branch, but in brief, yes, keep reusing your same branch for development.

Answer 2

the workflow you are describing seems reasonable in that it's similar to the git-flow workflow.

http://nvie.com/posts/a-successful-git-branching-model/ .

It's popular(i guess), so it would be reasonable to expect any developer to understand it. That's got to be worth something. I don't know what additional value could be had by varying it with a short lived dev-1.1 branch etc. it seems like the overhead of managing those would probably outweigh the cost.