敏捷中的语义版本控制

假设我进行了14天的sprint迭代，其中有多个新功能，改进和缺陷修复的故事。当更改准备就绪时，我也将对其进行部署，而不是等待sprint结束。

我的问题是-如何跟踪这样开发和维护的产品的语义版本控制？如果每14天发布一次，这将很容易，我将增加版本号并记下changelog中的所有更改。但是，如果不断部署变更怎么办？每次部署某些东西时都应该增加版本吗？还是我应该等到sprint结束，然后再进行“恢复”操作，并根据实际部署在每次迭代中单独增加一次版本号？敏捷中语义版本控制的最佳实践是什么？

编辑：为了更好地解释我的需求，我想首先为利益相关者提供变更日志。我认为他们在部署每次更改后都不会对changelog中的新记录感兴趣。

对于典型的发行版管理，您需要由构建系统生成一个内部版本号，以便在每次部署DLL时对它们进行版本控制。这将确保您以后可以检查在给定服务器上部署了哪个版本。

您通常会在发行说明中发布或发布到您网站上的“营销”版本不应每个版本都进行更新。这些发行说明应累积起来并分组在一起，并可能在冲刺结束时计时。

如果经典的语义版本控制方案“ MAJOR.MINOR.PATCH”有意义，则取决于您部署给谁，尤其是何时以及多长时间部署一次最终用户。如果使用稳定版本“ 4.5”（从4.5.0开始），该方案最有用。4.5.1、4.5.2等版本仅包含错误修复，而您内部已经在使用4.6版本。

例如，如果为最终用户提供“稳定分支”，则为初始部署提供4.5.0版本，并在发行补丁程序时为其提供4.5.1、4.5.2版本。在内部“敏捷”开发和中期打印部署中，您已经可以拥有4.6版，只需将其称为“测试版”即可。每当您在Sprint中期部署它时，请添加自动生成的内部版本号，例如“ 4.6.beta内部版本123”。当您的Sprint结束时，将其分配为“ 4.6.0”，然后在内部将下一个Sprint的版本号切换为“ 4.7”。以“ .0”开头只是一个惯例，您也可以使用“ .0”标记beta版本，并为最终用户以“ .1”开头。恕我直言，“ beta”一词更具表现力，告诉所有人“短跑尚未完成”。

如果您发布完整的最终用户更改日志，并且每个beta版本均由您决定，但是至少在冲刺结束时，更改日志应完成，并且每当向最终用户提供错误修正时，也应更新历史记录文件。

您会发现在许多开源产品（如Inkscape，Firefox或7-zip）中释放两个分离的分支，一个带有语义版本号的“稳定”分支和一个标记有内部版本号或类似名称的“开发分支”的策略。

但是，如果您不使用单独的稳定分支和开发分支，而是每天向最终用户发布新版本，则还应该每天增加一个版本号。在这种情况下，版本号“ 4.5.1”，“ 4.5.2”，...可能会反映您的个人部署，而不表示错误修复和其他更改之间的差异。可以，因为它不再是经典的“语义版本控制”。在这种情况下，您还可以部署版本4.5、4.6、4.7、4.8，这没有什么实质的区别。

关于您的变更日志中的条目的问题：恕我直言，当最终用户看到某些内容时，一旦部署变更，就值得在变更日志中添加一个条目。例如，如果使用功能切换并对尚未激活的某些半自动功能进行更改，则该功能不属于更改日志。如果仅进行重构，而对用户没有可见的更改，则该重构不属于更改日志。如果您修复了可能影响某些用户的错误，则该错误肯定属于变更日志-在部署错误修正的同时应在此提及。而且，每天发布，每月发布还是每年发布都没有关系。

我会使用内部版本号。通常，内部版本号将对应于版本控制系统的最高版本。如果星期一的内部版本号是1745，并且在星期二检查了5次更改，则星期二晚上的内部版本号将是1750。

然后简要概述一下1745年至1750年之间发生的变化。

然后，每次更新系统的版本号时，您都可以将构建中的所有简短摘要加起来，以获得从最新版本号到新版本的更改。

我至少已经使用了几年的首选方法是在完成每个故事后增加数量。这意味着在sprint末尾发布的版本将不是连续的，例如，在1.2.3之后，您可能会发现1.5.2而不是1.4.0。

在更改日志中，您可以列出中间版本及其相应的描述，也可以将所有更改分组到“已发布”版本中，并跳过它们之间的版本。

最初，我担心用户会发现版本号之间的“漏洞”是有问题的，但是一旦他们知道了这一点，实际上就不是问题。最大的优点是，每个故事后增加数量可以减少过程中出错的可能性-您不必从2周的时间就检查整个工作来确定下一个版本号-在查看单个故事时，很明显。此外，每个发行版之间版本号的“偏移”可以粗略估计该发行版中进行了多少更改。总而言之，我发现该系统可以很好地工作（这适用于公司内部的客户，但是如果您已经在敏捷的发布周期中工作，那么它也应适用于外部客户）。