公告：本站正在遭受网络攻击，访问速度可能严重下降甚至无法访问。

什么是Build：修订间差异

跳转到导航 跳转到搜索

什么是Build (查看源代码)

2024年1月30日 (二) 19:40的版本

删除39字节 、​ 2024年1月30日 (星期二)
→‎Build里的小秘密：​一堆奇怪的空格和“build”（应该为“Build”）
（→‎Build里的小秘密：​Windows 9X不严谨，请用Windows 9x）
标签：移动版编辑 移动版网页编辑
（→‎Build里的小秘密：​一堆奇怪的空格和“build”（应该为“Build”））
标签：移动版编辑 移动版网页编辑
第31行： 第31行：
时间：2016/08/31
时间：2016/08/31


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


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


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


255、256、（跳过去）300、301、302、303、304……
255、256、（跳过去）300、301、302、303、304……
257、258、259，Beta发布。
257、258、259，Beta发布。


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


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


开发者选定了700这个数；它对于任何顺其自然增加得到的Build 编号来说实在是太远了。除了一些稍大的留给Beta的区段之外，Build 编号每天只累进 1。要想到达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 9x产品线上这个数字游戏的惯例后来一直延续下去。Windows 98是Build 1998。Windows 98 SE是Build 2222。Windows ME是Build 3000。


在这一段时间，Windows NT那边的伙计们对这种做法是拒绝的，他们的Build 编号自然增加，到了哪里，就在哪里发布。当 Windows 9x的系统不再延续的时候，数字游戏看上去就要结束了？
在这一段时间，Windows NT那边的伙计们对这种做法是拒绝的，他们的Build 编号自然增加，到了哪里，就在哪里发布。当 Windows 9x的系统不再延续的时候，数字游戏看上去就要结束了？
第53行： 第53行：
'''数字里蕴含着什么？'''
'''数字里蕴含着什么？'''


开发者在 Windows XP 中梅开二度。Windows XP的最终Build编号被定为2600，作为对黑客杂志的致敬（指2600 Magazine: The Hacker Quarterly——译者注）。这一最终版本号向前跳了一些，和Windows 95的向前跳进理由是一样的：把最终的版本同之前的预览版区分开。
开发者在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 Build 6000；给了Windows 7 Build 7600。Windows 8本来应为Build 8888。事实上，团队——我（原作者）那时在其中——的确制作了那个版本号的Build，但我们发现了一个问题。8888这个数字不能被16整除。


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


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


而自从Windows Vista开始，发布版本的版本号必须是16的倍数。为什么？
而自从Windows Vista开始，发布版本的版本号必须是16的倍数。为什么？
第75行： 第75行：
把这些合起来，你会发现要用到二十位。然而修订版本号总共只有十六位的空间。结果服务团队只好想办法再从哪里挖出四位来。他们要求RTM的内部版本号是16的倍数，以此多霸占了四位空间。（因而Windows Vista、Windows 7在打上Service Pack之后内部版本号会变化，而不仅仅是修订版本号会发生变化——译者注）。
把这些合起来，你会发现要用到二十位。然而修订版本号总共只有十六位的空间。结果服务团队只好想办法再从哪里挖出四位来。他们要求RTM的内部版本号是16的倍数，以此多霸占了四位空间。（因而Windows Vista、Windows 7在打上Service Pack之后内部版本号会变化，而不仅仅是修订版本号会发生变化——译者注）。


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


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


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


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

个编辑

取自“https://www.betaworld.cn/特殊:移动版差异/73078”
我们提供服务需要使用Cookie。您使用我们的服务，即表示您同意我们使用Cookie。

导航菜单