title: How to use mercurial for release management?
body: <p>This is a cousin question with my <a href="https://stackoverflow.com/questions/3719019/how-to-manage-concurrent-development-with-mercurial">earlier question</a> of "How to manage concurrent development with mercurial", which covers individual developer workflow. The answer to this question will actually influence the choice for developer workflow.</p>
  
  <p>This is <em>NOT</em> a general "release management best practice" or CI question, as it has been <a href="https://stackoverflow.com/questions/134778/release-management-best-practice">asked</a> <a href="https://stackoverflow.com/questions/300703/what-release-management-solutions-are-worth-investigating">many</a> <a href="https://stackoverflow.com/questions/1714925/version-control-and-release-management">times</a> with good answers, and there's a huge body of literature available to kill time.</p>
  
  <p>I'm only asking for <strong>specific ways to use mercurial within the context of release management</strong>.</p>
  
  <p>The most obvious and predominant answer would supposedly be <strong>stable/default</strong>, which is thoroughly covered by the <a href="http://stevelosh.com/blog/2010/05/mercurial-workflows-stable-default/" rel="nofollow noreferrer">beautiful blog</a> of @Steve Losh, and more concisely in <a href="https://stackoverflow.com/questions/1405604/managing-release-branches-in-mercurial/1406906#1406906">an answer</a> from him. It's simple and effective.</p>
  
  <p>A prominent example of this setup is hg itself. hg uses <a href="https://www.mercurial-scm.org/wiki/DeveloperRepos" rel="nofollow noreferrer">a few more repositories</a> for active development, but for release management purposes everything seems to be contained in the stable/default branches of the <a href="https://www.mercurial-scm.org/repo/hg" rel="nofollow noreferrer">main repo</a>.</p>
  
  <p>The hg setup actually manifests a variation, or rather an extended version, of stable/default: <strong>branch clone</strong>. I described the process in <a href="https://stackoverflow.com/questions/890723/mercurial-named-branches-vs-multiple-repositories/3757525#3757525">an answer</a> to a question on named branch vs. multiple repos (with another <a href="https://stackoverflow.com/questions/890723/mercurial-named-branches-vs-multiple-repositories/890892#890892">great answer</a> from @Martin Geisler). What I forgot to mention in my answer is how branch clone works for developer workflow: if you need to fix a bug for a branch, you would <code>hg clone &lt;main repo&gt;#&lt;branch&gt;</code> but <em>not</em> the branch clone, because your changeset will still go back to the main repo and pushed out to branch clone automatically. Of course you can choose not to clone and just <code>hg update &lt;branch&gt;</code> in your main clone, but most arguments for using separate clones (especially the independent build) apply here.</p>
  
  <p>Now back to the question: <strong>Are there any other ways that fit different real-world scenarios?</strong> For example, a traditional major/minor/patch release cycle with long lapse between releases probably require quite a different workflow than a fast-paced, release-as-you-go web application. Please also comment on the stable/default and branch clone approaches if you feel like.</p>
  
  <p>Since this is almost a survey question, I can only try to accept the "best" answer subjectively. If I can get a few more answers than my developer workflow question, that is.</p>
  
  <p>Thank you for all your inputs!</p>