软件版本控制的3个有效技巧
软件版本控制的3个有效技巧
软件版本号五花八门。目前，我的系统报告了各种已安装软件的以下版本：
17.0
1.2.167.19
11.0.0
1.5.11 (1635)
1.6.0_37
23.0.1271.101
6.0.0.2968
玛雅末日 (96)
0.6.9
3.7.1 (M20110909-1335)
7.0 (Build 201104080000)
正如你所见，这里没有明确的模式。最常见的似乎是
<major>.<minor>.<patch>.<build>
公平地说，有一些尝试标准化版本号的尝试，例如 语义化版本控制、Apache APR，甚至更早的 Apple 标准。然而，……
并非所有软件都生而平等
我们有各种各样的软件，从库和框架，到复杂的服务器软件，再到简单的移动应用程序。有些软件的构建率很高（例如，每天几次），而在另一端，很容易找到每隔几个月甚至几年发布一次的常见情况。有些软件发布给公众，有些则保留在内部。很难为所有类型的软件定义一个通用的方案。因此，我们将软件分为以下三个大类：
- 库和框架
- 公共软件
- 内部或托管软件
库和框架
对于定义自己 API 的库组件和框架，语义化版本控制（SemVer）看起来很有希望。它要求软件必须定义一个公共 API 才能使用。从他们的 网页
“普通版本号必须采用 X.Y.Z 的形式，其中 X、Y 和 Z 是非负整数。X 是主版本号，Y 是次版本号，Z 是补丁版本号。每个元素必须按数值递增一个单位。例如：1.9.0 -> 1.10.0 -> 1.11.0。”
像 Express（Node.js）、Ruby On Rails 这样的 Web 框架可以从中受益。
公共软件
当涉及到公共软件时，事情就变得复杂了。让我们花点时间问问自己，为什么用户会使用版本信息？我脑海中唯一的答案是，他们通过版本信息来决定是否有新版本可供购买。回想我使用 Windows 95 并听说过 Windows 98 这个新奇事物的时候，我知道是时候升级了。
事情是这样的：你的用户并不真正关心晦涩的版本号。只有在用户遇到问题并打电话时，详细版本信息（如4.1.2222A）才有用，支持人员会想知道他们使用的软件的确切版本，一直到构建号。
因此，为公共软件采用双版本控制方案是个好主意：第一个版本是一个用户友好的名称，易于记忆和在随意讨论中使用，例如Lion。第二个是用于危机时期的详细版本，例如10.7.5 (11G63)，例如在互联网上查找已知漏洞或致电苹果寻求支持时。
微软似乎发明了，或者至少普及了双版本控制系统，从 Windows 95 开始。Windows 95，Windows 3.1x 的极其受欢迎的继任者，实际上被称为Windows 4.0。Windows 98 是4.1。苹果从 OS X 10.0 开始采纳了这个想法，并开始用猫的名字来命名主要版本（Cheetah、Jaguar、Panther，直到最新的 Mountain Lion）。你可以在构思用户友好的版本控制方案时发挥创意，甚至可以邀请营销部门参与其中。
对于详细的版本控制方案，我个人偏爱 <major>.<minor>.<revision>.<build>。你也可以使用 <major>.<minor>.<revision>.<date>。例如：
2.15.45.30098312345
1.0.3 (2012 年 12 月 21 日)
将日期嵌入发布版本实际上是个非常好的主意。它传达了构建生成的时间。其他人则喜欢附加构建管理系统（如 SVN、Git 或 Mercurial）生成的构建 ID。在我工作的地方，我使用以下规则：
- Major：这通常在完整的发布周期结束时进行；最终产品是重大升级。所有利益相关者（经理、副总裁、营销总监）都会被告知主要的版本增量，通常会伴随新闻稿和营销活动。
- Minor：当引入附加功能或新功能时。软件开发经理或高级开发人员通常会批准此类增量。
- Revision：Bug 修复、临时补丁、任何小的更改。开发人员每次进行小的更改或修复 Bug 时都会增加此数字。
- Build：这是版本中唯一自动生成的组件。有一个 Python 脚本，每次构建软件时都会使用 Git 提交 SHA 来生成它。
Alex Collins 在这篇 文章 中解释了递增每个组件的规则。
“在任何你递增的数字右侧，你都用零填充，所以如果你在版本 5.3.6 之后修复了一个 Bug 并引入了一个新功能，那么新版本就是 5.4.0。未声明的数字假定为零，所以 5.4.0 与 5.4.0.0 和 5.4.0.0.0.0.0.0.0…”
奖励：我写了一个 Java 类 来保存版本信息。它是在 MIT 许可下提供的，因此你可以自由使用它。.NET 用户可以使用框架自带的 Version 类。
内部或托管软件
对于使用 Jenkins 等自动化系统进行高频率构建，最好让版本自动带时间戳。诸如 <year>.<month>.<day>.<time> 之类的格式对于向支持台工作人员提供详细信息以及为开发人员引用构建信息都很有用。例如，2012.12.29.0059 是 2012 年 12 月 29 日凌晨 12:59 生成的构建版本。
保持一致
无论你做什么，请保持一致并坚持你选择的系统。Sun Microsystems（被 Oracle 收购）在其版本控制方案的更改过程中，让开发人员感到困惑。