这个问题混合了一些项目管理和开发。我理解[major]。[minor]。[patch]计划项目的版本编号。对于我的客户的项目，我使用这些编号主要是出于内部目的，所以团队不是通过所涉及的功能引用项目，而是可以说“v1.3.2的进展是什么？”。
但是，有时我们的客户会同时发布多个次要版本。每个次要版本都包含一组独立功能（与客户公司的不同部门合作），但两者都可以启动不同的时间。因此，如果我们将它们标记为v1.3.3和v1.3.4，则v1.3.4版本可能早于v1.3.3发布，然后整个命名方案无效。
如果您不知道哪个将首先发布（由于等待客户端批准或其他外部调度冲突），您如何在内部引用这些不同的版本？
谢谢！
答案 0 :(得分：1)
非常简单 - 在我们发布之前，我们不会分配版本号。问题解决了！
这可能听起来很轻浮，但这是事实。当然，我们会将内部项目称为例如“v5.5”，但是这些在v5.4.x的下一次迭代中是独立的，独立于当前的工作，只有在完成和发布时才会收到下一个“x”值。当v5.5准备就绪时，5.4停止工作，我们将对5.4的任何更改合并到5.5中，然后我们发布5.5.0。
如果您为不同的客户端（在您的情况下是部门）有单独的构建，则可以使用修改的版本控制方案。我们所做的是使用[major]。[minor]。[client]。[patch]，例如5.4.client1.4。 [patch]将是独立的，仅对该特定客户端有意义，而[major]。[minor]将对应于我们分叉的主代码库的[major]。[minor]版本。例如，我们可能同时在5.5,5.4.x和5.4.client1.x上工作。当5.5准备就绪时，5.4.x合并到那个，然后两个项目都折叠成5.5.x，但客户端项目可能还没有准备好合并所有这些更改，因此它将保持5.4.client1.x直到它被提起到5.5为止，然后变成5.5.client1.x。
这听起来可能令人困惑，但实际上对我们来说效果很好。我们以前使用过这种方案的变体，其中客户名称附加到完整版本号，即[major]。[minor]。[patch] _ [client];然而，[major]。[minor]对应于“核心”[major]。[minor]从哪里分叉/最后合并，[patch]完全独立于其他版本，只对那有意义客户端（这就是为什么我们后来交换了[client]和[patch]的相对位置，以明确表示例如5.4.7可能实际上有更多的修复/比5.4.12.client1更“当前”，并且更好传达这种独立性。
当客户特定项目合并回来时，当然，你放弃它并增加到下一个[补丁]，或者可能跳转到下一个[次要]甚至[主要]版本，具体取决于性质的工作。当客户端项目合并到5.4.x项目然后我们从该版本6.0发布时，这偶尔会导致一些暂时的混淆，然后记得将内部5.5项目重命名为6.1，但它仍然有效。
作为您环境的替代方案，仅通过客户（部门）名称在内部引用您当前的项目，例如：会计项目，人力资源项目等。不要在内部使用版本号来进行此类事情，因为正如您所看到的那样只会导致5.4.7之后但5.4.9之前出现的版本5.4.6混淆;同时5.4.8因为被取消而永远不会被释放。那只是一团糟，所以远离那个。只需按客户名称调用您的项目，然后分配下一个号码