什么是Build
Build概述
Build指程序的编译次数，中文可翻译为构建、内部版本等，在日常交流中通常不做翻译。
通常所指的Build都是内部版本号，即第三位版本号。
Build的重复现象
早期Windows开发阶段
在16位Windows时期，每一次新的开发，Build都要从0开始重新计数，所以会出现Build号码重复现象。
Windows 9x与Windows NT
由于内核的不同，9x和NT出现同Build的现象十分常见，比如:Windows 98 Build 1691和Windows 2000 Build 1691、Windows XP Build 2419和Windows Me Build 2419。
以上情况都可以通过其第一位和第二位版本号进行分辨。
而由于9x开发的停止，现在已经不会出现Build重复现象了。
第四位版本号的改变
第四位版本号即修订版本号。在Windows 10中，其内容在HKLM\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 Docs 和 The 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。我猜发布管理团队再加了两次修补。