如何验证新版本¶
简介¶
本文档包含关于测试即将成为下一个 LLVM 版本的候选版本的信息。有关如何管理实际发布的更多信息，请参阅 如何向公众发布 LLVM。
发布流程概述¶
一旦发布流程开始，发布经理将征集志愿者，并且每个志愿者的角色是
测试和基准测试之前的版本
测试和基准测试每个候选版本，与之前的版本和候选版本进行比较
识别、缩小范围并报告在测试和基准测试中发现的每个回归
确保关键 Bug 得到修复并合并到下一个候选版本中
并非所有的 Bug 或回归都是阻碍发布的，哪些应该在下一个候选版本之前修复，哪些可以等到下一个版本发布，这有点灰色地带。
这将取决于
Bug 的严重程度，影响的人数，以及它是回归还是已知 Bug。已知 Bug 是“不受支持的功能”，如果最近实现了某些 Bug，则可以禁用它们。
发布的阶段。不太严重的 Bug 应该考虑在 RC1 和 RC2 之间修复，但在发布结束时则不那么重要。
是正确性回归还是性能回归。性能回归往往比正确性回归更受重视。
脚本¶
脚本位于 utils/release 目录中。
test-release.sh¶
此脚本将分阶段检出、配置和编译 LLVM+Clang（+ 大多数附加组件，如 compiler-rt、libcxx、libomp 和 clang-extra-tools），并将测试最终阶段。它将在 Phase3/Releasei(+Asserts) 目录中安装最终二进制文件，这应该是您用于测试套件和其他外部测试的文件。
要在特定候选版本上运行脚本，请运行
./test-release.sh \
-release 3.3 \
-rc 1 \
-no-64bit \
-test-asserts \
-no-compare-files
每个系统都需要不同的选项。例如，x86_64 显然不需要 -no-64bit，而 32 位系统则需要，否则脚本将失败。
需要正确设置的重要标志是
在预发布版本中，您应该将
-rc 1更改为-final。在 RC2 上，将其更改为-rc 2，依此类推。在非发布测试中，您可以将
-final与-no-checkout结合使用，但您必须手动创建final目录，并将正确的源目录链接到final/llvm.src。对于候选版本，您需要
-test-asserts，否则它不会创建 “Release+Asserts” 目录，这是发布测试和基准测试所需的。这将花费双倍的时间。在最终候选版本中，您只需要 Release 构建，这将是您必须打包的二进制目录。
在 macOS 上，您必须在运行脚本之前导出
MACOSX_DEPLOYMENT_TARGET=10.9。
此脚本为 Clang+LLVM 构建了三个阶段，每个阶段两次（Release 和 Release+Asserts），因此请使用 screen 或 nohup 以避免麻烦，因为它会花费很长时间。
使用 --help 选项查看所有选项，并根据您的需要选择它。
findRegressions-nightly.py¶
TODO
测试套件¶
请按照 LNT 快速入门指南 链接了解如何设置测试套件
您必须用于测试的二进制文件位置位于 rcN/Phase3/Release+Asserts/llvmCore-REL-RC.install 中。将该目录链接到一个更方便的位置并运行测试套件。
一个运行命令行的示例，假设您从正确的安装目录创建了一个链接到 ~/devel/llvm/install
./sandbox/bin/python sandbox/bin/lnt runtest \
nt \
-j4 \
--sandbox sandbox \
--test-suite ~/devel/llvm/test/test-suite \
--cc ~/devel/llvm/install/bin/clang \
--cxx ~/devel/llvm/install/bin/clang++
与之前的版本或候选版本相比，它应该没有新的回归。您不需要修复测试套件中的所有 Bug，因为它们不一定旨在始终在所有架构上通过。这是由于结果检查的性质，它依赖于直接比较，并且大多数时候，失败与错误的输出检查有关，而不是错误的代码生成。
如果错误发生在 LLVM 本身中，请将发现的每个回归报告为 blocker，并将所有其他 Bug 报告为 important，但不一定阻止发布继续进行。它们可以设置为 “known failures”，并在未来某个日期修复。
预发布流程¶
当在邮件列表中宣布发布流程时，您应该为测试做准备，方法是在之前的版本上应用与您将在候选版本上进行的相同测试。
您应该
从 https://llvm.net.cn/releases/download.html 下载之前的版本源代码。
在
final模式下运行 test-release.sh 脚本（将-rc 1更改为-final）。一旦所有三个阶段完成，它将测试最终阶段。
使用
Phase3/Release+Asserts/llvmCore-MAJ.MIN-final.install基础，运行测试套件。
如果最终阶段的 make check-all 失败，最好也通过进入 obj 目录并运行 make check-all 来测试中间阶段，以查找是否至少有一个阶段通过（有助于缩小 Bug 报告的错误范围）。
发布流程¶
当发布经理向您发送候选版本时，下载所有源代码，在同一目录中解压缩（将有从适当位置到它们的符号链接），并如上所述运行发布测试。
您应该
从发布经理指向您的位置下载当前候选版本源代码（例如 https://llvm.net.cn/pre-releases/3.3/rc1/）。
使用
-rc 1、-rc 2等模式重复上述步骤，并以相同方式运行测试套件。比较结果，在 Bugzilla 上报告所有错误，并发布二进制 blob，以便发布经理可以获取它。
一旦发布经理宣布最新的候选版本是好的，您必须打包 Phase3 上的 Release（无 Asserts）安装目录，这将是官方二进制文件。
将
clang+llvm-REL-ARCH-ENV重命名（或链接）到 .install 目录从目录外部将其压缩为相同名称，扩展名为
.tar.gz使其可供发布经理下载
Bug 报告流程¶
如果您在将候选版本与之前的版本进行比较时发现回归或失败，请遵循以下规则
编译中的关键 Bug 应尽快修复，可能在发布二进制 blob 之前。
Check-all 测试应在下一个候选版本之前修复，但可以等到测试套件运行完成后再修复。
测试套件或不重要的 check-all 测试中的 Bug 可以在候选版本之间修复。
临近发布时的新功能或最近的重大更改，应该以易于禁用的方式完成。如果它们行为异常，则最好禁用它们，而不是发布不稳定的（但未经测试的）二进制包。