如何创建真正具有语义的版本号

引言

语义化版本控制（SemVer）是一项规范，为开发人员提供有关如何管理组件之间的 API 依赖性方面的指导。不幸的是，大多数开发人员创建的是不带 API 的业务线应用程序，这意味着 SemVer 对应用程序的用户来说并没有提供太多的语义（即意义）。

幸运的是，创建有意义的版本号，让每个人——开发人员、测试人员、运维人员、经理，甚至最终用户——都觉得有用，这其实相当容易。

在讨论版本号时，首先区分发布和构建是很重要的。这两者之间的区别并不总是显而易见的，尤其是在企业 IT 和其他定制软件部门。

简单来说，发布仅仅是需求；也就是说，对特定应用程序的一系列计划更改。而构建，另一方面，是尝试满足发布需求的举措；构建是实际通过开发、暂存和生产环境的东西。

虽然这看似微妙，但这是一个重要的区别，不亚于类与接口，以及虚方法与抽象方法。当你将构建和发布的概念结合在一起时，你就会面临在弄清楚谁在做什么、什么在哪里等方面的没必要挑战。

当然，在能够区分一次发布与下一次发布之前，你必须能够唯一地标识你的发布。将你的发布（即你计划的更改集）称为“暂存”或“下周二”显然是次优的。

选择发布编号方案

发布标识的两个最重要的方面是可用性和可伸缩性。

如果发布号的目标受众（无论是最终用户还是项目相关者）无法区分一次发布与下一次发布，那么标识的目的就达不到了。例如，一个发布号渐近地趋近于π（如 TeX 使用的方案）的方案会让许多不理解 3.141592 和 3.1415926 之间差异的非技术用户感到沮丧。

同样，如果一个发布标识系统无法扩展，那同样是无用的。一个明显的愚蠢例子是根据雪白七个小矮人的名字来命名发布，但一个更实际的例子可能是仅根据月份和年份来标识发布。当用户需要问“您指的是哪个 2010 年 7 月的发布？”时，这相当次优。

虽然几乎任何东西，从彩虹的颜色到巴洛克风格的作曲，都可以用来标识发布，但数字是最合适的。它们具有自然的顺序（3 总是 precedes 7）并且是普遍理解的。

有五种普遍认可的编号方案。没有一种是“正确”的，因为“可用性”和“可伸缩性”将决定适宜性。

主/次	大多数最终用户已经习惯了这一点，因为如今似乎一切（软件和非软件）都用一个“something-dot-something”的数字来标识；在大多数情况下，这是内部/定制应用程序最合适的选择。
主/次/修订	如果您需要“幕后”（即对最终用户或产品经理不透明）的发布来修复错误，那么这个版本很有用；对于产品公司来说是必备的，但对于内部开发来说通常会令人困惑。 请注意，SemVer 是这个方案的一个定义良好的版本：修订被补丁替换，修改为Major/Minor/Patch。
Sequential	也许最容易处理的是，这个方案只是为每次发布递增一个整数；主要缺点是无法在处理当前版本（例如 1.8、2.3）的同时为遥远的未来版本（例如 3.0、4.0）进行规划，这通常对于像静态网站这样非常简单的应用程序来说不是问题。
基于日期	基于目标发布日期，例如 2010Q4；虽然看起来方便，但当 2011 年 1 月的发布延迟到 3 月时，这个方案可能会令人困惑；对于相对不频繁且固定的发布计划（每月、每季度），这是一个合适的选择。
自由格式	其他所有；显然是最不理想的方案，因为它没有一致性，而且很少有人会天生理解它。

至于决定什么是一个主发布，什么是一个次要发布……这总是任意的。而且，正如微软通过 .NET 2.0/3.0/3.5 和 Windows 7/8/10 向我们展示的那样，这通常是最终由营销决定的。

构建 vs 发布 vs 版本号

一旦您区分了构建和发布的概念，您就可以看出构建标识符实际上只需要在生产前阶段使用，以区分一个构建与下一个构建。一旦一个构建被发布到生产环境，被拒绝的构建就仅仅是历史的遗迹，而发布号是描述应用程序已发布版本的全部所需。

发布号只需要在应用程序内部是唯一的，同样，构建号也只需要在发布内部是唯一的。做到这一点最简单、最直接的方法是一个自动递增的整数，为每个新发布从“1”开始，类似于顺序发布编号方案，但它可以是任何值。

对于构建号，其因素的细微之处要少得多，最重要的标准是开发组织（开发人员、测试人员等）成员之间的沟通，并且使用一个非常长的数字（或 LongGuid）是不切实际的。

那么版本号在这一切中又扮演什么角色呢？它是由应用程序名称、发布编号和构建编号的任意组合，以便在给定上下文中，用一个简短的字符串向相关方传达最相关的信息。在大多数情况下，您可以通过简单地共享发布编号来达到这一点。

有关 BuildMaster 中发布的详细说明，请参阅我们的 BuildMaster 发布文档。