问更新多个开发人员之间的语义版本

EN

通常，这是通过通信来处理的。主要版本是罕见的和有计划的，因此它们绝大多数都是提前计划和交流的。

对于小版本和补丁版本之间的区别，通常有某种分支方案。例如，Git在3.1.x分支中使用像release-3.1这样的分支，对于次要版本使用main。所有的代码都会进入main，然后如果需要进行补丁发布，更改就会被选中到release-*分支中。核心团队讨论下一个版本的计划，以及他们是否希望下一个定期发布小版本，或者他们是否认为补丁发布是必要的。

当然，还有很多其他的方法来处理这个问题，而这只是其中之一。但是，无论如何，开发人员之间就项目和计划的期望进行沟通是很重要的，因此这是决定项目希望如何处理此类问题的理想方法。

这个难题只是由于人们对版本控制实际工作方式的误解而产生的。扪心自问：“我这里的版本是什么？”

将版本号保存在由修订控制的文件中是一种长期的做法，开发人员可以在该文件中修改版本号。在后视眼，这是一个可怕的做法，但实际上对我们在当时是有意义的。但是，让我们停下来思考一下，我们现在的版本控制是什么，看看在现代开发系统中是如何跟踪所有各种工件的。

今天的一个最佳实践是使用修订控制系统自动跟踪对文件的更改，这在几十年前并不常见。开发人员在进行更改时，不再需要记住在每个源文件的顶部加一个修订号。相反，RCS在提交文件时跟踪文件版本(不是在每个更改上！)。不过，大多数不同的RCS提供了自动更新源文件头的方法，但是这种做法现在很少使用，因为它是多余的/浪费的，而且扩展得不好。

今天的另一个最佳实践是在发布工件上使用某种形式的语义版本控制，而且工具中有很多支持它的变化，但其中大多数都嵌入在少数打包工具和包归档服务/提要中。请注意，并不是源代码中的每一个更改都需要在这里增加版本。RCS跟踪开发人员提交的单个更改，发布/发布管理系统确定适用于打包工件的适当版本。

今天的主要最佳做法是使用建设管道。现代DevOps最佳实践是在托管服务器上为所有形式的发布构建产品。您通常有独立的内部和外部发布需求，但它们都是在受控的、非开发人员环境中构建的。

添加诸如语义提交(Brk、NB、NIB和许多其他符号)之类的内容来提交消息、自动测试结果和发布/发布策略，并且可以自动导出适用于任何工件的适当版本号。

建议的政策是：

没有一个开发人员能够将工件发布到面向公众的feed.

• Developer版本中，这是基于可用于回购哈希的最高版本的版本，再加上一个-a.Dev。

• No -a.Dev.预先发布的工件应该在开发人员之外共享，开发人员自己的workstation.

• Continuous集成构建应该在内部作为YYYY.MMDD.Increment-a.Integration

• Etc.

发布

请注意，可能的变化是无穷无尽的，取决于您的组织内部需求和对客户的承诺。

回到您的难题上，现在应该很明显，对于源代码中的每一次更改，更改版本号都是一种谬误。现代工具和最佳实践否定了对它的需求，并且不再需要它。

如果您在这里查看我的答案历史，您应该会发现，为什么RCS不是跟踪版本号的正确位置，但最主要的原因是，我们只是不使用RCS来存储我们发布的工件。为了开发人员的方便，可以将发布标记添加到特定的RCS状态，但是对于CI/CD环境，保持产品版本号的最佳位置是在您的发布提要系统或独立的数据库中。