什么是 Build

来自BetaWorld 百科

Build 概述

Build 指程序的编译次数,中文可翻译为构建、内部版本等,在日常交流中通常不做翻译。

通常所指的 Build 都是内部版本号,即第三位版本号。

Build 的重复现象

早期 Windows 开发阶段

在 16 位 Windows 时期,每一次新的开发,Build 都要从 0 开始重新计数,所以会出现 Build 号码重复现象。

Windows 9x 与 Windows NT

由于内核的不同,9x 和 NT 出现同 Build 的现象十分常见,比如:Windows 98 Build 1691Windows 2000 Build 1691Windows XP Build 2419Windows Me Build 2419

以上情况都可以通过其第一位和第二位版本号进行分辨。

而由于 9x 开发的停止,现在已经不会出现 Build 重复现象了。

第四位版本号的改变

第四位版本号即修订版本号。在 Windows 10 中,其内容在 HKCM\Software\Microsoft\Windows NT\CurrentVersion\UBR 内。

一般安装累积更新,Windows 8.1 Update 或 Service Pack 就会更新第四位版本号,在早期的 Service Pack Beta 里也可以称第四位版本号为 Build。如 Build 3311

Build 里的小秘密

以下内容来自:Windows Confidential: Numerology of the build - Microsoft DocsThe numerology of the build, redux——The Old New Things, 感谢 Bilin Sun 的介绍和翻译。

正文如下:

“给 Windows 的发布版本指定版本号是管理人员可以皮一下的机会。”

作者:Raymond Chen 时间:2016/08/31

我们倒回 1993 年的时候。微软刚把 Windows NT 3.1 推向市场,build 版本号 528。原因很简单。它是官方的第 528 个 build。 这个数值没有任何的意思,还是按照是什么就是什么。刚好那样而已。好吧,也可能不一定是第 528 个。并行开发会导致一些 build 号被跳过。

比方说,现在的 build 版本号是 256,如果你想要发布一个 beta,就要另创建一个专为 beta 版本的源代码树。Beta 树编译出来的 build 沿用原来的号码序列,于是接下来的 build 编号即为 257、258 等等。主代码树的 build 版本号跳过一段留出空间,于是编号为 300、301、302 等等。

管理 build 的人会选一个足够大的空隙,以便容下可预见的将来能拿出足够稳定的 beta 之前编译的若干 build,还能留下充足的空间以备万一。因此,build 号往往按这样发展:

255、256、(跳过去)300、301、302、303、304…… 257、258、259,beta 发布。

试图“节约”build 编号没有什么意义。它们只是数字,又不会有什么代价。重要的是不能让两个 build 的编号撞车。

在华盛顿州雷德蒙德,微软的另一个团队在 1993 年在做 Windows 95。这个系统最终作为 build 950 发布。这个数字就有些意思,显然是就“95”做文章。也有实际的作用:它帮助软件的开发者识别他们的软件是否运行在最终版本的 Windows 而不是一个预览版上。他们问起发布的情况时就会被告知:“检查一下 build 编号。要是大于 700,那就是最终版本了。”

开发者选定了 700 这个数;它对于任何顺其自然增加得到的 build 编号来说实在是太远了。除了一些稍大的留给 beta 的区段之外,build 编号每天只累进 1。要想到达 build 700 以上,就只可能是人为修改的了。

Windows 9X 产品线上这个数字游戏的惯例后来一直延续下去。Windows 98 是 build 1998。Windows 98 SE 是 build 2222。Windows ME 是 build 3000。

在这一段时间,Windows NT 那边的伙计们对这种做法是拒绝的,他们的 build 编号自然增加,到了哪里,就在哪里发布。当 Windows 9X 的系统不再延续的时候,数字游戏看上去就要结束了?

数字里蕴含着什么?

开发者在 Windows XP 中梅开二度。Windows XP 的最终 build 编号被定为 2600,作为对黑客杂志的致敬(指 2600 Magazine: The Hacker Quarterly——译者注)。这一最终版本号向前跳了一些,和 Windows 95 的向前跳进理由是一样的:把最终的版本同之前的预览版区分开。

开发者一直皮一直爽,给了 Windows Vista build 6000;给了 Windows 7 build 7600。Windows 8 本来应为 build 8888。事实上,团队——我(原作者)那时在其中——的确制作了那个版本号的 build,但我们发现了一个问题。8888 这个数字不能被 16 整除。

Windows Vista 引入了最终版本号必须是 16 的整倍数的要求。服务团队定下了这个规则好让他们使用 build 号的最低四个比特来表示附加信息供内部使用。不幸的是我们不能用次佳的选项 8800,因为 build 号不能回头(那是会让更新都乱套的)。

经过考虑,我们选中了最终 的 build 号 9200。不好意思,这数就不好玩了。研究数字的人可能会注意到在过去的几次发布当中,build 号每次刚好前进 1600。尽管看上去很神奇,我认为当中没有什么内幕。

而自从 Windows Vista 开始,发布版本的版本号必须是 16 的倍数。为什么?

版本号由四个十六位(bit)的整数组成:主版本号(major)、次版本号(minor)、内部版本号(build)、修订版本号(revision)。主版本号和次版本号反映了开发计划上的系统版本。像有些人由于程序上的(programmatic,指供程序读取以识别版本如 10.0.10240.16384,区分于 human readable,人类可读的如 Windows 10 1507——译者注)主次版本,就管 Windows 7 叫 6.1 版本。微软自己人是不这么叫的;我们就叫它 Windows 7。

Build 号随着每次 build 实验室做出一个 build 而增加,虽然偶尔有些跳跃。

修订版本号被维护团队掌管着。他们要记录这些信息:

  • 四位的 service pack 编号(0 代表 RTM);
  • 一位表示这是否是个非 milestone 的 build(我不知道这具体是什么意思);
  • 一位表示该 build 是否准备要公开发放;
  • 两位表示这个 build 来自哪个发布通道。0=GDR,1=LDR,2=(未使用),3=私有 build;
  • 十二位用来编码服务版本号(servicing build number)。¹

把这些合起来,你会发现要用到二十位。然而修订版本号总共只有十六位的空间。结果服务团队只好想办法再从哪里挖出四位来。他们要求 RTM 的内部版本号是 16 的倍数,以此多霸占了四位空间。(因而 Windows Vista、Windows 7 在打上 service pack 之后内部版本号会变化,而不仅仅是修订版本号会发生变化——译者注)。

Windows 10 带来的服务堆栈当中的变化之一是服务团队重新设计了他们的版本编号系统,只需要十六位而不用二十位了。我(原作者)并不知道他们是如何做到的;我只知道他们不再要把内部版本号保持为 16 的倍数了。

Windows 部门的大多数人对这个服务堆栈改变并不很清楚。通知说明发布管理团队希望 build 10584 成为 1511 更新的版本时,很多人感到难以置信:“你在逗我?它不是 16 的倍数!”²

¹这正好够五年的主流支持周期的日常更新用,应该不是一个巧合。

²是,1511 更新最后的内部版本号是 10586。我猜发布管理团队再加了两次修补。