什么是有用的分支版本策略？

Question

我们已经转向产品版本控制方法,它将根据以下格式标记/增加构建:[Major].[Minor].[Build].[Revision/Patch]和生产版本基本上是主要或次要的增量(取决于更改的范围).

这对于补丁和Trunk构建非常有用,但对于分支中的并发功能开发来说效果不是很好 - 特别是因为很可能我们会在分支上构建候选版本而不是合并到Trunk并释放(不是我喜欢的选项,但很可能不幸的是,更加现实.

无论我们是否合并到主干(或不是),是否有人有任何有用的策略来处理分支版本控制？我们需要能够从分支和主干中唯一地识别构建,并且可能在任何给定时间从主干或分支中释放.

一些考虑:

• 我们可能事先不知道发布顺序是什么,因此尝试在逐个分支的基础上假设次要版本应该是不可能解决问题的.
• 我们可以在产品编号中添加另一个数字,表示分支(如果适用),但它在逻辑上会位于何处？

(轻量级)场景可能会有所帮助:

Product X\Trunk (ver 1.1.208.0)
Product X\Branches\Feature A (ver 1.1.239.0)
Product X\Branches\Feature B (ver 1.1.221.0)

编辑:到目前为止我发现的最好的文档位于MSDN上,虽然它对并发分支的独特版本有点模糊.

Answer 1

我不会将版本号与功能分支联系起来，因为在并发开发场景中，您可能需要考虑：

• 仅是功能的一部分（功能中并非所有内容都已准备好发布）
• 多个功能（如果一个功能依赖于另一个功能），这意味着您需要发布多个功能作为新版本的一部分
• 次要或主要版本：并非每个稳定点都会仅增加构建，某个功能可能会引入次要或主要更改

对于每个新x.y版本，我宁愿有一个专门的合并分支，我可以在其中合并为下一个版本选择的所有功能分支（因为某些功能可能无法及时准备好），并且该x.y部分有意义。

换句话说，我会将功能开发周期与发布周期分开。