同时版本编号

非常简单-在发布之前，我们不会分配版本号。问题解决了！ 听起来有些flip昧，但这是事实。当然，我们会有内部项目，例如\“ v5.5 \”，但它们与v5.4.x的下一个迭代中的当前工作是独立且独立的，后者仅在完成并发布后才接收\'x \'的下一个值。 v5.5准备就绪后，将不再对5.4进行任何工作，我们将对5.4所做的所有更改合并到5.5中，然后发布5.5.0。 如果为不同的客户端（在您的情况下是部门）有单独的版本，则可以采用修改后的版本控制方案。我们所做的是使用[major]。[minor]。[client]。[patch]，例如5.4。客户端1.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]对应于\“ core \” [major]。[minor]，它是从那里分叉/最后合并的，并且[patch]完全独立于其他版本，仅有意义客户端（这就是为什么我们后来交换[client]和[patch]的相对位置的原因，以明确表示，例如5.4.7实际上可能比5.4.12.client1具有更多的修复/更多的“当前”） ，并更好地传达这种独立性。 当然，当特定于客户的项目合并回来时，您可以将其放下并增加到下一个[patch]，或者根据工作的性质跳到下一个[minor]甚至[major]版本。 。当客户端项目合并到5.4.x项目中，然后我们从该版本6.0发行时，这确实偶尔会引起一些暂时的混乱，然后记住将内部5.5项目重命名为6.1，但是仍然可以工作。 作为您环境的替代方案，内部仅通过客户（部门）名称来引用您当前的项目，例如在这种情况下，请不要在内部使用版本号，因为如您所见，这只会导致版本5.4.6混乱，例如在5.4.7之后但在5.4.9之前发布；同时5.4.8从未发布，因为它已被取消。那只是一团糟，所以请远离它。只需通过客户名称调用您的项目，然后分配下一个号码