在某些方面，版本编号方案可以很像标签对空格，或者emacs对vi。你知道那种战争，即使标签是邪恶的，错误的人也会继续战斗，emacs比vi更难退出。然而，我感兴趣的是，在选择一个版本编号方案而不是另一个版本编号方案的背后，往往有着非常有趣的原因。在这种情况下，我想与您分享一下我们选择cloudbeedevoptics组件内部使用的版本编号方案的原因可能会很有趣。如果你不喜欢阅读博客文章，你可能会对我录制的同一主题的视频感兴趣：我们还需要版本号吗？如果您正在开发一个纯网站，其中客户只使用web浏览器进行交互，那么您的代码实际上没有太多的暴露面。你也许可以将Git提交哈希作为一个版本公开，因为它实际上只对开发人员重要。随着我们为应用程序添加特性和复杂性，我们开始发现使用版本号的一些优势。如果我们在我们的网站上添加一个restapi。。。现在，您不仅要向浏览器公开，还要向客户编写的调用REST服务的代码公开。客户可能会就restapi的版本向您施压，以便他们能够找出自上次更新集成以来发生了什么变化。您可能只需将上次修改的日期作为版本公开就可以了。您的客户在编写REST客户机时遇到问题。它们总是不正确地添加授权头，因此您决定为它们编写一个客户端库。现在您不仅提供了网站，还提供了restapi客户端库。现在，您将交付两个可交付成果，其中一个嵌入到客户的代码中。您已经失去了完全控制在生产环境中随时部署代码的版本的能力。您无法控制客户何时更新您提供的客户机库。您需要引入一些版本编号方案，即使只是为了让您的技术支持人员使用"您运行的是什么版本？"？哦，你能升级到最新版本吗？"修复策略！Semver怎么了我以前就这个话题发表过一些强烈的意见。老实说，Semver没有什么特别的错误，只是它不是普遍适用的。Semver方案使用三个组成部分：主要.次要.修补其中递增：当您更改不兼容的API时，以向后兼容的方式添加功能时的次要版本，以及当你做向后兼容的错误修复时的补丁版本。如果您正在开发单个模块或库，那么Semver是一个很好的选择。当您有多个模块时，您要么需要将Semver独立地应用于每个模块，要么将Semver应用于整个聚合。当你将这一点与Git的最佳实践结合起来时，即只有共享相同版本号的模块才应该在同一个Git存储库中。例如，在我们的案例中，Run Insights存储库至少有三个组件：我们有REST客户机和restapi后端都使用的数据传输对象。数据传输对象几乎从未发生过重大变化。我们可以将它们托管在三个独立的存储库中，并分别管理它们的发布生命周期，但是在一个非常小的DTO模块中协调更改会变得相当复杂。对我们来说，Semver的另一个问题是目前无法实现Semver的自动化。听起来很简单：更改不兼容的API时，增加主版本，但问题是如何决定何时API更改不兼容。当然，如果您更改了方法签名和/或类名，这是一个不兼容的API更改，我们可能会得到工具来帮助检测这些情况。。。但API也是它的行为。如果方法停止接受空值，这对某些客户来说可能是一个突破性的变化。。。事实上，如果它开始接受null并停止抛出特定的异常，这甚至可能是一个破坏性的API更改。也许一个特定的调用序列会导致不同的行为。。。所有这些都是不兼容的API更改。。。但是没有通用的工具可以捕捉这些变化并声明"我们应该做一个主要的版本转换"。我们在DevOptics中使用连续部署，所以我们需要一个对自动化鲁棒的方案。对于我们来说，塞默棺材里的最后一个钉子是，我们无法控制客户何时升级他们的插件。所以我们的服务需要向后兼容。实际上，我们不能因为客户的影响而改变不兼容的API。我们的选择最后我们决定了以下方案：EPOCH.COMMIT\u计数.释放计数EPOCH表示版本编号方案。对于Run Insights，这是1，但是对于较早的Value Streams服务（它有以前的版本编号方案），这是2。如果我们改变版本编号方案，我们将增加历元。COMMIT_COUNT是规范Git存储库主分支上的提交数。我们在CI/CD服务器上运行我们的所有版本，它只从规范的Git存储库构建。我们启用了GitHub的protectedbranchs功能，以防止"git push--force"倒回提交计数。释放计数通常为0并被忽略。如果需要重新运行特定提交的某个版本，则每次重新运行时，将释放数量增加一个。此版本控制方案对我们有一些有用的属性：数字比提交哈希更不容易出错。考虑一下"版本1.1205"与"版本7a42d0f89"之间的通信有多困难。如果您正在与客户进行支持电话，那么通过音频电话可以更容易地获得版本号。我们的方案允许在一天内根据需要提供任意多个版本。我们可以使用基于日期的版本号，但是考虑一下"版本1.1205"和"版本201902191642"。。。即便如此，我们每分钟只能有一个版本。版本号是严格递增的，因此我们知道如果一个数字更大，那么它就是新的。版本号"jump"反映了更改的数量。如果在GitHub上查看提交计数，则版本是可预测的：您可以立即知道版本号，即1205提交将是版本1.1205。在版本1.1205中将JIRA问题标记为已解决非常方便，而不必等待CI/CD部署作业的完成，从而使您可以自由地进行下一个任务。结论对于Semver版本的编号方案有很多可以说的，但是请记住，它并不是普遍适用的。考虑您希望在版本号中编码的功能，然后选择方案。Stephen Connolly有超过20年的软件开发经验。他参与了许多开源项目，包括Jenkins。Stephen是Jenkins项目的首批非Sun成员之一，他开发了天气图标。史蒂芬住在爱尔兰都柏林，那里的天气图标特别有用。