如何验证新版本¶
简介¶
本文档包含有关测试候选发布版本的信息，这些版本最终将成为下一个 LLVM 版本。有关如何管理实际发布的更多信息，请参阅 如何向公众发布 LLVM。
发布流程概述¶
发布流程开始后，发布经理会征求志愿者，每个志愿者的职责是
测试和基准测试上一个版本
测试和基准测试每个候选发布版本，并与上一个版本和候选版本进行比较
识别、减少和报告在测试和基准测试期间发现的每个回归
确保关键错误得到修复并合并到下一个候选发布版本中
并非所有错误或回归都是严重问题，在下一个候选版本之前应该修复哪些问题以及哪些问题可以等到下一个版本再修复，这有点模糊。
这将取决于
错误的严重性、影响的人数以及它是回归还是已知错误。已知错误是“不受支持的功能”，如果某些错误是最近实现的，则可以禁用它们。
发布阶段。在 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。
此脚本分别两次（Release 和 Release+Asserts）构建三个阶段的 Clang+LLVM，因此请使用 screen 或 nohup 以避免出现问题，因为它将花费很长时间。
使用 --help 选项查看所有选项，并根据您的需要进行选择。
findRegressions-nightly.py¶
待办事项
测试套件¶
请按照 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++
与上一个版本或候选发布版本相比，它不应该有新的回归。您不需要修复测试套件中的所有错误，因为它们并不一定总是需要在所有架构上都通过。这是由于结果检查的性质，它依赖于直接比较，并且大多数情况下，错误与错误的输出检查有关，而不是与错误的代码生成有关。
如果错误在 LLVM 本身中，请报告发现的每个回归错误为 blocker，并将所有其他错误报告为 important，但不一定阻止发布继续进行。它们可以设置为“已知故障”，并在将来某个日期修复。
预发布流程¶
当在邮件列表中宣布发布流程时，您应该准备进行测试，方法是在上一个版本上应用与您在候选发布版本上执行的相同的测试。
您应该
从 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 报告流程¶
如果您在比较候选发布版本与上一个版本时发现回归或错误，请遵循以下规则
编译中的严重错误应尽快修复，可能在发布二进制 Blob 之前。
check-all 测试应在下一个候选发布版本之前修复，但可以等到测试套件运行完成后再修复。
测试套件中的错误或不重要的 check-all 测试可以在候选发布版本之间修复。
接近发布时，新功能或最近的大型更改应以易于禁用方式进行。如果它们出现异常行为，优先禁用它们，而不是发布不稳定（但未经测试）的二进制软件包。