如何驗證新版本¶
簡介¶
本文檔包含關於測試發布候選版本的資訊，這些候選版本最終將成為下一個 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¶
待辦事項
測試套件¶
依照 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 上報告所有錯誤，並發布二進制 blob，以便發布管理員可以抓取它。
一旦發布管理員宣布最新的候選版本是好的版本，您就必須封裝 Phase3 上的 Release（沒有 Asserts）安裝目錄，這將是官方二進制檔案。
將
clang+llvm-REL-ARCH-ENV重新命名（或連結）為 .install 目錄從目錄外部將其壓縮為具有
.tar.gz副檔名的相同名稱使其可供發布管理員下載
錯誤回報流程¶
如果您在將發布候選版本與先前的版本進行比較時發現回歸或失敗，請遵循以下規則
編譯中的嚴重錯誤應盡快修復，可能在發布二進制 blob 之前。
Check-all 測試應在下一個發布候選版本之前修復，但可以等到測試套件執行完成。
測試套件或不重要的 check-all 測試中的錯誤可以在發布候選版本之間修復。
接近發布時的新功能或最近的重大變更，應以易於停用的方式完成。如果它們行為不當，寧願停用它們，也不要發布不穩定（但未經測試）的二進制套件。