如何驗證新版本¶
簡介¶
本文件包含有關測試最終將成為下一個 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。
這個腳本會分別構建 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++
與之前的發布版或候選發布版相比，它應該沒有新的回歸。您不需要修復測試套件中的所有錯誤，因為它們不一定在所有架構上始終都能通過。這是由於結果檢查的性質，它依賴於直接比較，並且在大多數情況下，失敗與錯誤的輸出檢查有關，而不是與錯誤的代碼生成有關。
如果錯誤在 LLVM 本身，請將發現的每個回歸都報告為阻礙因素，並將所有其他錯誤報告為重要錯誤，但不一定會阻礙發布進程。它們可以設置為「已知錯誤」，並在將來修復。
預發布流程¶
當在郵件列表上宣布發布流程時，您應該通過對先前版本應用與您將在候選發布版上執行的相同測試來為測試做好準備。
您應該：
從 https://llvm.dev.org.tw/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 來測試中間階段，以查找是否至少有一個階段通過（有助於在減少錯誤報告目的的錯誤時）。
發佈流程¶
當發佈管理員向您發送候選版本時，請下載所有原始碼，並解壓縮到同一個目錄（將會有符號連結從適當的位置指向它們），然後如上所述執行發佈測試。
您應該：
從發佈管理員指示的位置下載當前的候選原始碼（例如 https://llvm.dev.org.tw/pre-releases/3.3/rc1/）。
使用
-rc 1、-rc 2等模式重複上述步驟，並以相同的方式執行測試套件。比較結果，在 Bugzilla 上報告所有錯誤，並將二進制檔案發佈到發佈管理員可以取得的位置。
一旦發佈管理員宣佈最新的候選版本是可行的，您必須將 Release（無斷言）安裝目錄打包在 Phase3 上，這將成為正式的二進制檔案。
將
clang+llvm-REL-ARCH-ENV重新命名（或連結）到 .install 目錄從目錄外部使用
.tar.gz副檔名將其打包成相同的名稱讓發佈管理員可以下載它
錯誤回報流程¶
如果您在比較候選版本與先前版本時發現回歸或錯誤，請遵循以下規則
編譯過程中的嚴重錯誤應盡快修復，可能在發佈二進制檔案之前。
所有檢查測試都應該在下一個候選版本發佈之前修復，但可以等到測試套件執行完成。
測試套件中的錯誤或不重要的檢查測試可以在候選版本之間修復。
接近發佈時，新功能或最近的大改動應該以易於停用的方式完成。如果它們出現問題，最好停用它們，而不是發佈不穩定（但未經測試）的二進制套件。