两种不同发布周期的Hg工作流

Question

作为从CVCS (TFS)升级到DVCS (Hg)的一部分，我们即将改变发布管理的工作流程。有些事情在办公室里讨论得很激烈，我很高兴能得到一些关于这方面的意见。

一些背景

我们是一家中小型软件公司。( 25名开发人员)与一个长寿的产品。我们试图保持我们的发行周期低-在每次冲刺之后发布(每个月一次)。在TFS中，我们为每个新版本创建一个分支。最后两个版本支持错误修复。

我们目前的分支模式(TFS)

--trunk
  --release200 //and older, not supported anymore
  --release201
  --release202

在这些分支之上，我们有不同的开发人员分支(如果需要的话)。一些团队分支和一些特性分支。

“小”错误在release202上被纠正并合并到主干中。在release201上纠正了关键错误，并将其合并到202号版本和主干中。

我们不支持的是旧版本的bug修复。

新工作流

有些客户不太关心新特性，而是想要一个更稳定的版本。因此，我们正在考虑提供两个轨道-一个长期存在的版本与补丁，另一个更频繁的更新功能。我们一直在考虑有这样的分支..。

(Hg)

--default
  --RC
  --Release
  --StableRelease200
  --StableRelease210

这些都是在中央汞存储库中命名的分支。每个分支都连接到一个CI机器上。从开发人员的角度来看，在这个问题的范围之外将有开发分支(hg克隆)。

一些客户将使用发行版的版本，有些将使用StableReleaseX的版本。

默认值：所有新特性的开发都合并到这个分支中。

RC:当PBI完成/结束一个sprint时，缺省值被合并到这个分支中进行内部测试。在这个分支中发现的Bugs也在这里得到了纠正。当QA认为它足够稳定时，这个分支就被合并到发行版中。如果一些开发人员需要继续开发新功能，他们可以在默认情况下这样做。

发行版:这里的发布是按顺序进行的，只有最后一个版本将支持错误修复。从技术角度看，释放是用汞标签标记的。在sprint过程中在客户站点发现的关键错误将在这里修复并合并到默认状态。

StableReleases:每半年左右(由管理层决定)，发行版将合并到一个新的StableRelease分支中。在它的生命周期，没有新的功能将在这里添加。这里发现的Bugs将在这里修复并合并回默认状态。可能同时支持两个StableReleases --当前的一个和最后的一个。旧的分支机构将被关闭。

几个问题

• 对工作流的一般看法？你有任何经验支持两个不同的，并行的“发行轨道”吗？一个是频繁发布，另一个是只修复bug的长寿命版本？
• 我们一直在考虑将分支命名为分支，以使开发人员更容易(一比一，一拉等等)。或者..。你觉得会更难吗？更容易分离克隆(大多数开发人员使用DVCS的经验有限)？

Answer 1

请在Mercurial wiki中看到关于“标准”分支的wiki页面。您会很高兴地了解到，它描述的工作流非常类似于您建议的工作流！:-)所以是的，有两个类似于此的发布轨道非常有效。

至于使用命名分支而不是克隆，那么我们对我们在Mercurial项目本身中使用的两个名称分支非常满意。我们以前有两个存储库，但现在有了一个default和一个stable分支。

有些人更喜欢服务器上的独立克隆，原因是它可能会给出更好的概述：“分支”然后显示为单独的存储库。