袖珍指南：发布 Firefox¶
预计阅读时间： 15 分钟
简介¶
本文档的目的是提供对 Mozilla 如何发布 Firefox 的高级理解。旨在帮助新的 Mozilla 贡献者（以及那些希望复习的人）了解我们发布流程、工具、常用术语以及用于向用户发布 Firefox 的机制的基础知识。本文档通常会介绍一个概念，解释它如何在流程中发挥作用，然后提供链接以供感兴趣的人进一步学习。
代码库 & 发布通道¶
发布 Firefox 遵循软件发布列车模型，沿着 3 个主要的代码代码库进行；mozilla-central（又名“m-c”）、mozilla-beta 和 mozilla-release。每个代码库都在定义的节奏内更新，并构建成我们的 Firefox 产品之一，这些产品通过通常称为发布通道的方式发布：Firefox Nightly、Firefox Beta 和 Firefox Release。
Firefox Nightly 提供对仍在积极开发中的最新尖端功能的访问。每 12 小时发布一次，包含已落地到 mozilla-central 的所有更改，适用于桌面和 Android。
每4 周，我们合并来自 mozilla-central 到我们的 mozilla-beta 分支的代码。对于 Android，我们从 firefox-android 上的主分支创建到发布分支。可以在此 4 周节奏之外向 mozilla-beta 添加新代码或功能，但需要将其落地到 mozilla-central，然后提升到 mozilla-beta。类似地，对于 Android，需要在回退到 firefox-android 发布分支之前，将提升落地到 firefox-android 上的主分支。
Firefox Beta 适用于希望查看和测试 Firefox 中即将推出的内容的开发者和早期采用者。我们每周发布三次新的桌面/Android Beta 版本。
注意
新周期中的第一个和第二个 Beta 版本会发布到我们 Beta 用户群的一部分。完整的 Beta 用户群从 Beta 3 开始更新。*
每个 Beta 周期持续 4 周，在此期间，我们的质量保证团队会验证最终版本，并将其标记为发布到桌面版的 mozilla-release 分支。在 Android 上，我们从 Beta 周期中使用的同一发布分支发布。
注意
Firefox Developer Edition 是基于 mozilla-beta 代码库的独立产品，专门针对 Web 开发人员定制。
Firefox Release 每 4 周发布一次，是我们 Beta 周期的最终结果。这是我们向数亿用户发布的主要产品。在发布上线后，临时更新（点版本）用于在下一个主要版本发布之前向用户发布重要的错误修复。当有足够重要的驱动因素（例如严重影响某些用户产品可用性的严重错误）时，可以根据需要进行这些更新。为了提供更好的可预测性，还计划在初始上线后两周安排一次计划的点版本发布，用于修复不太严重的错误和其他附带修复，这些修复被认为风险足够低，可以包含在内。
注意
Firefox ESR（扩展支持版本） 是专为企业用途设计的独立产品。主要更新每年发布一次，以保持稳定性和可预测性。ESR 还包含标准 Firefox Release 中不可用的许多策略选项。次要更新与 Firefox Release 计划同步发布，仅用于安全和选定的质量修复。
进一步阅读/有用链接
落地代码和发布特性¶
Mozilla 贡献者（Mozilla 公司的雇员和更广泛的社区）在 Mozilla 代码库中落地大量代码：修复、增强、兼容性、新功能等，并由Mercurial（又名 hg）管理。所有新代码都在Bugzilla中跟踪，在Phabricator中审查，然后使用Lando检入 mozilla-central 代码库。
注意
一些团队在开发过程中使用GitHub，但仍需要使用 Phabricator（在 Bugzilla 中跟踪）将其代码检入 mozilla-central hg 代码库。
将代码交付给用户的标准流程是“搭乘列车”，这意味着它已落地到 mozilla-central，在那里它等待下一个 Beta 周期开始。合并到 Beta 后，代码将在 4 周内稳定（以及从 mozilla-central 合并的所有其他内容）。在 Beta 周期结束时，将生成一个发布候选版本（RC）构建，对其进行彻底测试，并最终成为 Firefox 的下一个版本。
进一步阅读/有用链接
此流程的例外情况…¶
并非所有代码都可以简单地等待正常的列车模型将其包含在 Firefox 构建中。这有很多原因；关键修复、安全问题、稳定已在 Beta 中的功能、更快地发布高优先级功能等等。
在这些情况下，可以请求提升，以获取 mozilla-central 中的最新落地，并将特定部分合并到标准列车模型之外的其他代码库中。在 Bugzilla 中提出请求后，发布管理将评估潜在风险，并决定是否接受。
进一步阅读/有用链接
确保构建稳定性¶
在将代码落地到 mozilla-central、搭乘列车到 Firefox Release 的整个过程中，来自各个团队的许多里程碑和质量检查点。此流程旨在确保每次发布新版本时，都能始终如一地向用户交付高质量且引人入胜的产品。请参见下文，了解这些里程碑的简化列表。
里程碑 |
周 |
星期几 |
|
合并日 |
Nightly W1 |
星期一 |
新 Nightly 周期的第一天 |
PI 请求截止日期 |
Nightly W1 |
星期五 |
高风险功能的手动质量保证请求截止日期 |
功能技术文档到期 |
Nightly W2 |
星期五 |
需要手动质量保证的功能的截止日期 |
Beta 发布说明草稿 |
Nightly W4 |
星期三 |
|
Nightly 功能 Go/No-Go 决策 |
Nightly W4 |
星期三 |
|
功能完成里程碑 |
Nightly W4 |
星期四 |
落地风险补丁和/或启用新功能的最后一天 |
Nightly 软代码冻结开始 |
Nightly W4 |
星期四 |
为合并到 Beta 做准备的稳定期 |
质量保证测试计划批准到期 |
Nightly W4 |
星期五 |
向质量保证提供功能测试计划签字的最后一天 |
字符串冻结 |
Nightly W4 |
星期五 |
不允许修改或删除公开给最终用户的字符串 |
质量保证预合并回归测试完成 |
Nightly W4 |
星期五 |
|
合并日 |
Beta W1 |
星期一 |
新 Beta 周期的第一天 |
预发布签字 |
Beta W3 |
星期五 |
发布前的最后一轮质量保证测试 |
Firefox RC 周 |
Beta W4 |
星期一 |
验证发布候选版本构建，为下一个 Firefox Release 做准备 |
发布说明准备就绪 |
Beta W4 |
星期二 |
|
“新增功能”页面准备就绪 |
Beta W4 |
星期三 |
|
Firefox 上线时间为太平洋标准时间上午 6 点 |
Release W1 |
星期二 |
新 Firefox Release 发布到 25% 的 Release 用户的第一天 |
Firefox Release 提升到 100% |
Release W1 |
星期四 |
将新 Firefox Release 的部署增加到 100% 的 Release 用户 |
计划的点版本发布批准请求到期 |
Release W2 |
星期五 |
所有请求均需在当天结束前提交 |
计划的点版本发布上线 |
Release W3 |
星期二 |
默认情况下，在准备好时发布。具体时间可根据要求提供。 |
发布管理团队（又名“Relman”）监控并执行此流程，以保护 Firefox 的稳定性。Relman 的每个成员都会轮流对给定的发布周期进行端到端所有权。某个周期的 Relman 所有者将专注于整体发布、阻碍性错误、风险、回退率、稳定性/崩溃报告等。请访问此处以全面了解Relman 发布流程清单。
注意
虽然 Relman 会持续监控每个 Release 的整体运行状况，但工程组织有责任确保其落地的代码质量高，并且了解潜在风险。每个 Release 都有一个指定的回归工程所有者（REO），以确保对在发布中报告的每个回归做出决策。*
进一步阅读/有用链接
启用/禁用代码 (首选项)¶
在 Firefox 中，我们允许使用首选项 <preferences>启用/禁用代码片段或整个功能。这样做有很多好处。以下是一些示例
在多个发布周期内持续开发，而不会将未完成的功能公开给我们的用户
提供在发布过程中发现问题时快速禁用功能的能力
控制实验性功能或尚未准备好显示给特定发布通道用户群的功能（例如，在 Beta 中启用，但在 Release 中禁用）
通过遥测实验进行 A/B 测试
注意
Normandy 首选项推出是一项功能，允许 Mozilla 更改目标用户群的首选项状态，而无需部署 Firefox 更新。这在进行实验或将高风险功能逐步推出到我们的 Release 用户群时特别有用。
进一步阅读/有用链接
发布 & 特性质量保证¶
发布质量保证会定期并在整个发布周期内执行。以两周为一个冲刺进行组织，其主要目标是
为发布限定构建
特性测试
产品完整性请求
错误处理
社区参与
可能对代码库产生重大影响和/或构成风险的特性，应由其目标发布中的特性所有者提名以获得质量保证支持。此流程通过提交产品完整性团队请求PI 请求启动。这些请求的截止日期为 Nightly 周期的第 2 周结束。
注意
手动质量保证测试仅在特性经历 Beta 周期时才需要。Nightly 特性测试始终是可选的。
进一步阅读/有用链接
实验¶
当我们向用户交付新功能时，我们不断地思考其潜在影响，包括正面和负面影响。在许多新功能中，我们将进行实验来收集有关这些影响的数据。实验的一个简单定义是：衡量产品变更如何影响人们使用产品的方式。
一个实验包含三个部分
可以有选择地启用的新功能
一组用于测试新功能的用户
用于衡量人们如何与新功能交互的遥测数据
实验由一个名为Experimenter的内部工具管理。
进一步阅读/有用链接
请求新的实验（请参阅“帮助”链接了解更多信息）
定义¶
审批标记 - 表示补丁的安全审批或提升请求的标记。
Bugzilla - 基于 Web 的通用错误跟踪系统和测试工具。
渠道 - 开发渠道，为 Windows、Mac、Linux 和 Android 发布 Firefox 的并发版本。
Chemspill - 化学泄漏的简称。Chemspill 是指产品快速进行的安全驱动或关键稳定性点发布。
渠道会议 - 每周两次的会议，与发布团队一起检查活动版本的发布状态。
点发布驱动因素 - 足以保证对 Firefox 发布渠道进行次要点发布的问题/修复。通常用于修复稳定性（顶级崩溃）或安全（Chemspill）问题。
早期 Beta 版 - 通过启用 EARLY_BETA_OR_EARLIER 来控制功能的 Beta 版。周期中 Beta 版发布的前两周是早期 Beta 版发布。
功能所有者 - 最终负责开发高质量功能的人员。通常是工程经理或产品经理。
Fenix - 也称为 Firefox 预览版，是一款基于 GeckoView 和 Android 组件的全新 Android 浏览器。
Github - 基于 Web 的版本控制和协作平台，供软件开发人员使用。
GTB - “Go to build”的首字母缩写。主要用于发布计划沟通（“3 月 18 日开始构建”），表示我们开始构建特定版本。
落地 - 代码合并到特定源代码存储库中的通用术语。
Lando - Mozilla 的自动化代码落地工具。它与我们的Phabricator 实例集成，可用于将修订版落地到各种存储库。
Mercurial - 一个源代码管理工具（类似于 git），允许用户跟踪本地源代码的更改并与他人共享更改。也称为 hg。
合并 - 用于描述在 Mozilla 存储库中集成和协调文件更改过程的通用术语。
Nightly 软代码冻结 - Mozilla-central 夜间周期最后一周，在合并到 Beta 之前，在此期间不鼓励在存储库中落地有风险或实验性的代码。
Normandy - Normandy 是一组服务器、工作流和 Firefox 组件，使 Mozilla 能够根据精确的标准远程控制野外版本的 Firefox 客户端。
Nucleus - 发布经理用来准备和发布发行说明的内部应用程序的名称。该应用程序中的数据由 mozilla.org 获取。
Orange - 也称为不稳定或间歇性测试。描述测试或测试套件可能间歇性失败的状态。
Phabricator - Mozilla 的基于 Web 的软件开发协作工具套件实例。阅读更多关于Phabricator 作为产品的信息。
PI 请求 - 产品完整性请求的简称，是一种表单提交请求，用于联系 PI 团队以获取各种服务。最常用于请求功能 QA，也可以用于安全、模糊测试、性能以及许多其他服务。
首选项 - 首选项是可以设置（例如启用或禁用）的任何值或定义的行为。通过用户界面更改首选项通常会立即生效。这些值会保存到磁盘上的用户 Firefox 配置文件（在 prefs.js 中）。
候选发布版本 - 有可能成为最终产品的 Beta 版，除非出现重大错误，否则已准备好发布。
RC 周 - 发布上线前的一周称为 RC 周。在本周内，会生成和测试 RC 版本。
发布周期 - Firefox 发布产品的开发和成熟阶段的总和。
回归工程所有者 - 分配给每个发布的发布管理合作伙伴。他们既要保持对我们进展情况的心理状态，又要确保对发布中报告的每个回归做出决定。也称为REO。
发布工程 - 主要负责维护构建管道、签名机制、更新服务器等的团队。也称为releng。
发布管理 - 主要负责管理、计划、安排和控制软件构建通过不同阶段和环境的过程的团队。也称为relman。
Relnotes - 发行说明的简称。Firefox Nightly、Beta 和 Release 版本都附带发行说明。
存储库 - 从现有数据库中存储的数据集合合并为一个，以便在整个组织中共享、分析或更新。
顺风车 - 影响发布用户但未被认为足够严重到无需识别点发布驱动程序即可发布的错误修复。
推出 - 将发布版本交付给一定比例的发布用户。
状态标记 - 表示错误相对于 Firefox 发布版本的状态的标记。
字符串冻结 - 在此期间，不允许引入、修改或删除向最终用户公开的字符串，以便我们的本地化人员翻译我们的产品。
taskcluster - 我们的执行框架，用于在多个操作系统、硬件和云提供商上构建和运行测试。
遥测数据 - Firefox 衡量并收集非个人信息，例如性能、硬件、使用情况和自定义设置。Mozilla 使用此信息来改进 Firefox。
列车模型 - 一种软件发布计划形式，其中一系列不同的版本化软件发布作为多个不同的“列车”按定期计划发布。
跟踪标记 - 一个 Bugzilla 标记，指示是否正在调查某个错误以在 Firefox 发布版本中进行可能的解决。标记为 tracking-Firefox XX 的错误是必须在特定发布版本发布之前以某种方式解决的错误。
限制/解除限制推出 - 限制是将发布推出限制为发布用户群的 0%，用户仍然可以选择更新，但不会自动更新。解除限制是移除发布推出的限制。
提升 - 从软件系统（mozilla-central 或 mozilla-beta）的新版本中获取部分内容并将其移植到同一软件的旧版本（mozilla-beta、mozilla-release 或 ESR）中的操作。