title: Hg workflow with two different release cycles
body: <p>We're about to change our workflow for our release management as part of our upgrade from a CVCS (TFS) to DVCS (Hg). Some things have been discussed pretty intense here at office and I would be glad to get some input about it.</p>
  
  <p><strong>Some background</strong></p>
  
  <p>We're a small/midsized software company (approx. 25 developers) with a long lived product. We try to keep our release cycles low - a release after each sprint (~once a month). In TFS we create a branch for each new release. The two last releases supports bug fixes.</p>
  
  <p><em>Our current branch model (TFS)</em></p>
  
  <pre><code>--trunk
    --release200 //and older, not supported anymore
    --release201
    --release202
  </code></pre>
  
  <p>On top of these branches we have different developer branches (if needed). Some team branches and some feature branches.</p>
  
  <p>"Small" bugs are corrected on release202 and merged to trunk. Critical bugs are corrected on release201 and merged to release 202 and trunk.</p>
  
  <p>What we don't support is bug fixes on older releases.</p>
  
  <p><strong>New workflow</strong></p>
  
  <p>Some customers don't care that much about new features, instead they want a more stable version. Therefore we are thinking about offering two tracks - one long lived release with patches, another with more frequent updates of features.
  We've been thinking about having branches like this...</p>
  
  <p>(Hg)</p>
  
  <pre><code>--default
    --RC
    --Release
    --StableRelease200
    --StableRelease210
  </code></pre>
  
  <p>These are all named branches inside a central Hg repository. Each of these branches is connected to a CI machine. From a developer perspective, there will be develop branches (hg clones) outside the scope of this question.</p>
  
  <p>Some customers will use releases from Release, some from StableReleaseX.</p>
  
  <p><strong>Default:</strong> All new development of features is merged into this branch.</p>
  
  <p><strong>RC:</strong> When a PBI is done/end of a sprint, default is merged into this branch for internal testing. Bugs found in this branch is also corrected here. When QA thinks it's stable enough, this branch is merged into Release. If some developers need continue to work on new features, they can do it on Default.</p>
  
  <p><strong>Release:</strong> Releases here happens sequentially, only the last one will support bug fixes. From a technical perspective, releases are marked with Hg Tags. Critical bugs found at customer site during a sprint will be fixed here and merged back to default.</p>
  
  <p><strong>StableReleases:</strong> Every half year or so (decided by management), Release is merged to a new StableRelease branch. During its life time, no new features will be added here. Bugs found here will be fixed here and merged back all the way to default. Probably two StableReleases will be supported at the same time - the current one and the second last. Older branches will be closed.</p>
  
  <p><strong>Some questions</strong></p>
  
  <ul>
  <li>General opinions about the workflow? Do you have any experience in supporting two different, concurrent "release tracks"? One with frequent releases and one with long lived releases with bug fixes only?</li>
  <li>We’ve been thinking having the branches as named branches to make it easier for the developer (one VS, one pull etc). Or... do you think it will be harder? Easier to have seperate clones instead (most of the developers have limited experience using a DVCS)?</li>
  </ul>