製作 Subversion 版本 ¶

   1.0.1  -->  first stable patch release of 1.0
   1.1.0  -->  next stable minor release of 1.x after 1.0.x
   1.1.1  -->  first stable patch release of 1.1.x
   1.1.2  -->  second stable patch release of 1.1.x
   1.2.0  -->  next stable minor release after that

   version 1.7.1-dev (under development)

Alpha 和 beta 發布 ¶

當我們希望在進入正式穩定期之前，讓新功能獲得廣泛測試時，我們有時會發布 alpha 和 beta tarball。即使有「alpha1」、「alpha2」等版本，也不需要執行任何 beta 版本；我們可以跳到「rc1」。然而，在某些情況下，beta 版本會很有用：例如，如果我們不確定 UI 決策，並希望在將其固定為正式候選版本之前獲得更廣泛的使用者回饋。

Alpha 和 beta 版本僅適用於想要協助測試，並且了解在最終版本發布之前可能會出現不相容變更的人員。簽署需求由版本管理員自行決定。通常，RM 每個平台只會要求 1 或 2 個簽署，並告訴簽署者，即使他們的測試顯示輕微失敗，只要他們認為該程式碼足夠穩定，值得其他人測試，他們仍然可以簽署。RM 應要求簽署者在簽署時附上任何錯誤的說明，以便在宣布 alpha 或 beta 版本時可以發布這些問題。

當公開宣布 alpha 或 beta 版本時，應嚴正警告發行套件打包者不要打包它。請參閱Hyrum K. Wright 的這封郵件以取得良好的範例。

中斷相容性 ¶

我們的相容性規則（如下所述 詳述）僅在已通過並發布最終 x.y.0 版本後才開始套用。出現在主幹或 alpha/beta/rc 預發布版本中的任何 API、線路協定和磁碟格式均不受任何相容性承諾約束；如果我們發現有充分的理由，我們可能會在最終發布之前任意變更這些內容。我們甚至可能會完全移除我們不滿意的介面或序列化格式。

這對於持續性資料（工作副本和儲存庫）來說尤其是一個問題，因為我們可能不會在最終發布版本中提供升級路徑（舊版格式的程式碼路徑或指定指令碼）。（當然，我們可能會為測試我們預發布版本的開發人員和使用者提供此類指令碼；但我們沒有義務這樣做。）因此，預發布版本絕不應該被用於任何需要長期安全保存的資料。

同時，我們希望提醒讀者，指出 API 設計錯誤的最佳時機是在它們發布並定稿之前，換句話說，是在最初設計和預發布階段。

重複使用發布名稱 ¶

如果需要由於非程式碼問題（例如，封裝故障）而快速重新發布發布版本或候選發布版本，只要 tarball 尚未 通過簽署認可，就可以重複使用相同名稱。但是，如果已將其上傳到具有簽名的標準發行區域，或者如果重新發布是因使用者可能執行的程式碼變更所致，則必須捨棄舊名稱並使用下一個名稱。

如果在將要發佈的 tarball 發佈並公告給使用者之前，舊名稱被拋棄，則拋棄的名稱被視為非公開發佈，且文件（例如 CHANGES 和標籤的記錄訊息）應更新以反映這一點。（請參閱 1.8.7 以取得範例。）拋棄發佈的標籤和 tarball 會保留在儲存庫記錄中，但它們不受一般用途支援（相反地，它們已知具有發佈阻斷錯誤）。

概觀 ¶

次要和主要號碼版本在發布之前會經歷一段穩定期，並在發布後仍維持在維護（錯誤修正）模式。若要開始發布程序，我們會 根據最新的主幹建立一個「A.B.x」分支。

新 A.B.0 版本的穩定期通常會持續四週，讓我們可以進行保守的錯誤修正並找出重大問題。穩定期會從版本為 A.B.0-rc1 的候選版本 tarball 開始。當阻擋錯誤修正後，可能會製作進一步的候選版本 tarball；例如，如果發現一組語言繫結已中斷，那麼在修正這些繫結時明智的做法是製作新的候選版本，以便可以測試這些語言繫結。

建立 A.B.x 分支後，不會直接提交任何原始碼變更；變更會在投票通過後，按照下一節所述的程序，從主幹回傳至 A.B.x 分支。

穩定期最後一週開始時，如果自上次後有任何待處理的重大變更，應建立新的候選版本 tarball。穩定期的最後一週保留給重大錯誤修正；次要錯誤的修正應延後至 A.B.1 版本。重大錯誤是非邊界情況崩潰、資料毀損問題、重大安全漏洞，或其他同等嚴重的問題。

在某些情況下，穩定期會延長

• 如果必須進行可能造成不穩定的變更來修正錯誤，整個為期四週的穩定期會重新開始。可能造成不穩定的變更是指可能以無法預測的方式影響 Subversion 的許多部分，或涉及新增大量新程式碼的變更。任何不相容的 API 變更（僅在新的版本為 A.0.0 版本時才允許）都應視為可能造成不穩定的變更。

• 如果在穩定期的最後一週進行重大錯誤修正，最後一週會重新開始。最後的 A.B.0 版本始終與一週前建立的候選版本相同（但有以下討論的例外情況）。

A.B.0 版本發布後，當錯誤修正有需要時，會進行修補版本（A.B.1、A.B.2 等）發布。修補版本不需要四週的浸泡期，因為只有保守的變更會納入其中。

哪些變更符合回傳資格 ¶

某些類型的提交可以在不重新開始浸泡期的情況下納入 A.B.0，或在不影響測試行程或發布日期的情況下納入後續版本

• 無需投票

  • 變更 STATUS 檔案。

  • 修正文件。

  • 變更為發行簿記的正常部分，例如，發行版本 和 建立和維護發行版本分支 中列出的步驟。

  • 發行經理變更 dist.sh，或經理核准變更。

  • 變更 .po 檔案中的訊息翻譯或新增 .po 檔案。

• 投票

  • 任何僅影響 tools/、packages/ 或 bindings/ 的內容。

  • 變更列印輸出，例如錯誤和使用訊息，只要格式字串「%」代碼及其參數未更動即可。

注意：訊息翻譯變更的要求比 C 程式碼中的文字訊息寬鬆。允許變更 .po 檔案中的格式 специ符號，因為它們的有效性可以機械檢查（使用 GNU gettext 的 msgfmt 的 -c 旗標）。如果使用 GNU gettext，則會在建置時執行此動作。

當然，核心程式碼變更需要投票，並重新開始浸泡或測試期間，否則變更可能會未經充分測試。

投票概觀和選民 ¶

必須先在 A.B.x/STATUS 檔案中提出變更至 A.B.x 系列。每個提案包含一個簡短的識別區塊（例如，主線或相關系列提交的修訂編號，或可能是問題編號）、變更的簡要說明、最多一行說明為何應該在 A.B.x 中、一些備註/疑慮，最後是投票。備註和疑慮旨在成為簡短摘要，以幫助讀者了解方向。請勿使用 STATUS 檔案進行實際討論；請改用 dev@。

以下是範例，可能與條目一樣複雜

   * r98765 (issue #56789)
     Make commit editor take a closure object for future mindreading.
     Justification:
       API stability, as prep for future enhancement.
     Branch: 1.8.x-r98765
     Notes:
       There was consensus on the desirability of this feature in
       the near future; see thread at http://... (Message-Id: blahblah).
       Merge with --accept=mc.
     Concerns:
       Vetoed by jerenkrantz due to privacy concerns with the
       implementation; see thread at http://... (Message-Id: blahblah)
     Votes:
       +1: ghudson, bliss
       +0: cmpilato
       -0: gstein
       -1: jerenkrantz

任何人都可以投票，但只有參與領域的正式提交者和部分提交者才有約束力投票。當提交者投下不具約束力的票（例如部分提交者對其提名領域外的變更進行投票）時，他們應將其票註解為不具約束力，如下所示

 * r31833
   svndumpfilter: Don't match prefixes to partial path components.
   Fixes #desc4 of issue #1853.
   Votes:
     +1: danielsh, hwright
     +1 (non-binding): stylesen

這種區別在各種投票中都有體現，包括回溯投票、版本投票和神話般的因未能達成共識而導致的投票，但原因不同。在版本投票中，這種區別是版本進入 ASF 法律保護的法律要求，而在回溯投票中，它更接近於建議性區別。畢竟，如果有人出於充分的理由對變更投下 -1 票，他們的認證並不重要；如果他們的分析正確，變更將不會回溯。同樣，如果變更未收到所需數量的約束性 +1 票，但有一些不具約束力的 +1 票，這可能有助於其獲得批准。

換句話說，回溯流程的目的是確保不穩定的變更不會進入修補版本。投票通過迫使每個變更接受一定程度的審查來實現這一目的。由於業力不可轉移，我們用約束性票數來衡量「審查量」，但一如既往，任何人都可以對流程提供意見並被傾聽。

投票類型 ¶

投票者對變更的意見編碼為 +1、-1、+0 或 -0。

定義「否決」或參照定義

如果您投下否決票（即 -1），請在疑慮欄位中說明原因，並附上清單討論的網址或訊息識別碼（如果有）。如果您在提交否決票時無法取得討論串，您可以稍後再回頭新增連結。

投下 -0 票表示您對變更有些許疑慮，請在 dev@ 中說明您的理由，或在括號中加以總結，但不會阻礙共識形成。

對變更投下 +1 票不表示您僅在原則上同意。這表示您已徹底檢閱變更，並認為變更正確且盡可能不造成中斷。當變更提交至發行分支時，記錄訊息將包含所有投下贊成票的人員姓名，以及原始作者和提交變更的人員。所有這些人員都被視為對錯誤負有同等責任。提交者應了解自己的知識不足，並謹慎投下 +1 票。

如果您已檢閱程式碼修補程式，並喜歡它，但有些保留，您可以寫下「+1（概念）」然後在清單上針對您的疑慮提出問題。如果您喜歡一般概念，但尚未仔細檢閱程式碼修補程式，您可以寫下「+0」。這兩種票數都不計入總數，但對於追蹤關注變更並可能願意花更多時間處理變更的人員來說，它們可能很有用。

需要多少票數 ¶

對於非 LTS（「常規」）發行版本，如果變更收到兩個 +1 且沒有否決票，則該變更獲得核准。（僅具約束力的票數才算數；請參閱上方說明。）

對於LTS 發行版本，如果變更收到三個 +1 且沒有否決票，則該變更獲得核准。（僅具約束力的票數才算數；請參閱上方說明。）

儘管有上述規定，對於任何發行版本，只影響非核心程式碼（例如工具、套件、繫結、測試腳本等）的變更，且不影響建置系統的變更，只要獲得一位全權提交者或該領域的部分提交者一個 +1，以及任何其他提交者至少一個 +0 或「概念 +1」，且沒有否決票，即可納入。

目標是讓至少兩雙眼睛審查變更，而無需要求每位審查者都具備與領域維護者相同程度的專業知識。這樣，人們可以審查一般健全性、準確的註解、明顯的錯誤等，而不必被迫聲明「是的，我了解這些變更的每個細節，並已測試過它們。」

如何將變更提名至狀態 ¶

在建議變更 STATUS 之前，您應該嘗試將其合併到分支中，以確保不會產生合併衝突。如果發生衝突，請從發布分支建立一個新的臨時分支，並合併您的變更並解決衝突。分支應命名為 A.B.x-rYYYY，其中 YYYY 是 STATUS 檔案中變更的第一個版本。在 STATUS 檔案中新增一個註解，說明臨時分支的存在，格式為 Branch: A.B.x-rYYYY 或 Branch: ^/subversion/branches/A.B.x-rYYYY 標頭（使用此確切格式；腳本會解析它）。如果變更涉及進一步的工作，您可以將這些版本合併到分支中。當從 STATUS 中移除此變更的項目時，也應移除此臨時分支，以避免 /branches 目錄雜亂。

在極少數情況下，也使用臨時分支，即必須對 A.B.x 分支進行變更，而該變更並非從主幹回溯的變更。

如果您提名一個項目，導致合併衝突，直到另一個提名合併，請在提名中註明。在項目中放置一個「依賴：」標頭；這將使每小時「偵測合併衝突的提名」buildbot 工作保持綠色。（「依賴：」標頭的值未解析。）

tools/dist/nominate.pl 腳本（在主幹中）自動化新增新提名的程序。相同的腳本還有一個 REPL 迴圈，可協助檢閱提名和投票的程序；請參閱 tools/dist/README.backport（在主幹中）。

注意：關於臨時分支的 STATUS 變更，包括投票，始終保留在主要發布分支上。

編輯 STATUS 和註解投票 ¶

在新增版本到其他人已投票的提名時，請用「(僅 rX)」註解他們的項目，以釐清他們已投票和未投票的部分，如下所示

   * r30643, r30653, r30785
     Update bash completion script.
     Votes:
       +1: arfrever (r30785 only), stylesen

明顯的修正 不需要提到「(僅 rX)」

如果您提交了透過 IRC 或其他方式傳達的他人投票，請在您的記錄訊息中註明。

安裝某些建置工具的原始版本 ¶

因此，發行分支已穩定，您正準備進行發行。進行的詳細資訊會由 release.py 輔助腳本自動化。若要執行此腳本，您需要 Subversion trunk 工作副本。執行 release.py -h 以取得可用子指令清單。

在您實際進行檔案前，您需要設定白淨滾動環境。此環境必須包含某些建置工具的原始版本。

重要的是，不要使用此軟體配送的版本，因為它們通常會以不可移植的方式進行修補（例如，Debian 的 libtool 修補程式：#291641、#320698。）通常應重新考慮 tools/dist/release-lines.yaml 中提供的版本號，並在 A.B.0 版本發布之前將其增加到最新的穩定上游版本。僅應仔細考慮後才變更 A.B.x 系列中的版本。

Autoconf、Libtool 和 SWIG：選擇一個目錄來放置 Subversion RM 職責所需的特製建置工具，例如 /opt/svnrm。使用 release.py build-env 指令設定、建置和安裝這三項軟體。

mkdir -p /opt/svnrm && cd /opt/svnrm && $SVN_SRC_DIR/tools/dist/release.py build-env X.Y.Z

安裝更多建置工具 ¶

滾動指令碼還需要下列指令可用：pax、xgettext、m4 和 python -c 'import yaml'。

從作業系統套件安裝這些指令。（在 Debian 系統上，指令為 apt install pax gettext m4 python-yaml subversion。）

為何要簽署版本 ¶

Subversion 版本透過全球 內容傳遞網路 (CDN) 發行。（自 2021 年底起，此網路已取代先前的 ASF 鏡像網路。儘管如此，仍可能存在其他組織選擇繼續鏡像 ASF 版本。）

最終使用者必須能夠驗證所下載原始程式碼套件的真實性非常重要。檢查碼足以偵測下載過程中發生的毀損，但為了防止惡意個人或鏡像操作員散布替代套件，每個原始程式碼套件都必須由 Subversion PMC 的成員 以密碼學方式簽署。這些簽章使用每個提交者的私人 PGP 金鑰進行，然後與版本一起發布，以便最終使用者可以驗證已下載套件的完整性。

投票和簽署需求 ¶

在 Subversion 發行版本正式公開之前，需要

• Subversion PMC 成員的 +1 票數三票 [ASF 政策]
，以及
• 我們支援的主要平台（Windows 和 *nix）上的 每個 平台至少一位 PMC 成員的測試和簽名 [專案政策]

如何簽署發行版本 ¶

在建立初始的 tarball 組時，發行版本管理員也會建立第一組簽名。儘管 tarball 本身可以在 people.apache.org 上建置，但重要的是，不要 在那裡產生簽名。簽署 tarball 需要私密金鑰，而 強烈不建議 將私密金鑰儲存在 ASF 硬體上。在簽署 tarball（使用以下流程）後，發行版本管理員應將簽名上傳到初步的發行位置，並將它們放在與 tarball 相同的目錄中。

鼓勵 PMC 成員以及熱情的社群成員從初步的發行位置下載 tarball，執行測試，然後提供他們的簽名。這些簽名的公開金鑰應透過 id.apache.org 包含在 ASF LDAP 實例中。（Subversion 提交者和 PMC 成員的 目前公開金鑰 清單每天會從 LDAP 自動產生。）建議發行版本管理員在宣布發行版本之前至少等待 5 天，以允許測試此版本的任何人完成在宣布之前簽署發行版本的動作。

簽署 tarball 表示您聲明它具備特定事項。在宣告您的簽署時，請在郵件中指出您已採取哪些步驟來驗證 tarball 是否正確，例如驗證內容與儲存庫中的正確標籤。對所有 RA 層和 FS 後端執行 make check 也是個好主意，以及建置和測試繫結。

若要取得發行候選版本，請查看 https://dist.apache.org/repos/dist/dev/subversion 的工作副本。驗證發行管理員在 tarball 上的 PGP 簽章。release.py 會自動執行此步驟

    release.py get-keys
    release.py --target /path/to/dist/dev/subversion/wc check-sigs 1.7.0-rc4

在驗證、解壓縮和測試 tarball 之後，您應使用 gpg 建立裝甲分離簽章來簽署。若要將您的簽章附加到 .asc 檔案，請使用類似下列的指令

    gpg -ba -o - subversion-1.7.0-rc4.tar.bz2 >> subversion-1.7.0-rc4.tar.bz2.asc

release.py 腳本可以自動執行此步驟

 release.py --target /path/to/dist/dev/subversion/wc sign-candidates 1.7.0-rc4

在新增您的簽章後，將修改後的 .asc 檔案提交至 dist.apache.org 儲存庫。

如果您已下載並測試 .tar.bz2 檔案，則可以對內容相同的 .tar.gz 檔案進行簽署，而無需另外下載和測試。訣竅是解壓縮 .bz2 檔案，並使用 gzip 進行壓縮，如下所示

    bzip2 -cd subversion-1.7.0-rc4.tar.bz2 \
    | gzip -9n > subversion-1.7.0-rc4.tar.gz

產生的檔案應與發行管理員產生的檔案相同，因此可以如上所述進行簽署。若要驗證檔案是否相同，您可以使用檢查碼或發行管理員的簽章，這兩者都應與 tarball 一起提供。

但是，如果檢查碼不相同，並不表示檔案簽章錯誤或檔案已被竄改。很有可能是您沒有與發行管理員相同的 gzip 版本。

上傳發布 ¶

Subversion 人工製品透過全球 內容傳遞網路 (CDN) 分發。原始碼 下載頁面 會自動協助使用者選擇合適的下載連結。我們通常只會在專案的發行目錄中，為受支援的發行版本主機最新的穩定版本，而所有之前的 Subversion 發布則可在 檔案 中取得。

將發布上傳至 CDN

release.py move-to-dist 1.7.0

此動作會將 tarball、簽章和檢查碼從 ^/dev/subversion 移至 ^/release/subversion。內容傳遞網路 (CDN) 大約需要 15 分鐘來接收新發布。檔案也將自動接收發布。雖然執行 move-to-dist 會移動簽章檔案，但提交者仍可以提交新簽章至 ^/release/subversion；不過，這些簽章需要大約 15 分鐘才會出現在 CDN 上。任何此類簽章都無法包含在發布公告中，除非自提交後已過 15 分鐘。

在這個時間點，發布版本可能已經公開可用，但仍建議在 CDN 接收後才宣布。在 15 分鐘的時段過後，讓 CDN 有足夠的時間同步，發布經理將會發送公告並將變更發布到 Subversion 網站，如下所述。

這也是清理 ^/release/subversion 中舊版本的好時機；該目錄中只應保留每個受支援版本線的最新版本。在 ^/release/subversion 中已提供至少 24 小時的版本將會持續保留在檔案中。您可以使用下列方式清理舊版本

release.py clean-dist

在 reporter.apache.org 上提交新版本的版本號碼。下列指令

curl -u USERNAME "https://reporter.apache.org/addrelease.py?date=`date +%s`&committee=subversion&version=VERSION&xdate=`date +%F`"

將會新增版本，它可能應該新增到 release.py。

更新網站 ¶

即使下列步驟指示直接更新已發布的網站，您也可以在 ^/subversion/site/staging 上準備變更。在這種情況下

• 從 ^/subversion/site/publish 執行追趕合併。

• 提交任何變更到 ^/subversion/site/staging，並在 https://subversion-staging.apache.org 上查看結果。

• 準備發布時，將變更合併回 ^/subversion/site/publish（檢閱合併，以防範 staging 上有其他尚未準備好合併的變更）。

對於任何版本，包括預先發布版本（alpha/beta/rc）

• 編輯 ^/subversion/site/publish/download.html 以註明最新版本。使用 release.py write-downloads 來產生表格。如果這是穩定版本，請更新 [version] 或 [supported] ezt 巨集定義（例如 [define version]1.7.0[end]）；如果這是預發行版本，請取消 <div id="pre-releases"> 的註解；如果這是 1.x.0 版本，會使預發行版本過時，請重新註解它。

• 將新的新聞項目新增到 ^/subversion/site/publish/news.html 來宣告版本。將相同的項目新增到 ^/subversion/site/publish/index.html 上的新聞清單中，同時也從該頁面中移除最舊的新聞項目。使用 release.py write-news 來產生範本新聞項目，然後應該自訂該項目。在新聞項目中有一個區段應該包含連結到宣告郵件。目前已註解它，稍後會新增連結。如果您在發行日期之前產生範本，請檢查日期是否正確。

此外，如果這是穩定版本 X.Y.Z（非 alpha/beta/rc）

• 在 ^/subversion/site/publish/doap.rdf 上列出新版本

  對於每個受支援的次要版本，都應該有一個 <release> 區段，其中 <created> 和 <revision> 會更新為目前的發行日期和修補程式版本號碼。請勿變更檔案中的任何其他內容（特別是 <Project> 下的 <created> 是建立 Subversion 專案的日期）。

• 在 ^/subversion/site/publish/docs/release-notes/release-history.html 上列出新版本

此外，如果這是新的次要版本 X.Y.0

• 在 ^/subversion/site/publish/docs/release-notes/index.html 的「受支援版本」區段中更新社群發行支援層級

• 在 release.py 中更新 supported_release_lines，並視需要移除舊行。

• 從 ^/subversion/site/publish/docs/release-notes/X.Y.html 中移除「草稿」警告

• 建立或更新 ^/site/publish/docs/api/X.Y 和 ^/site/publish/docs/javahl/X.Y 中的版本化文件快照，並確保這些目錄的同層目錄中的「latest」符號連結始終指向最新發行系列的目錄。

  範例

  VER=1.12
  DOCS_WC=~/src/svn/site/staging/docs
  TAG_BUILD_DIR=~/src/svn/tags/$VER.x/obj-dir
  cd $TAG_BUILD_DIR
  make doc
  cp -a doc/doxygen/html $DOCS_WC/api/$VER
  cp -a doc/javadoc $DOCS_WC/javahl/$VER
  for D in $DOCS_WC/api $DOCS_WC/javahl; do
    svn add $D/$VER
    rm $D/latest && ln -s $VER $D/latest
  done
  svn ci -m "In 'staging': Add $VER API docs." $DOCS_WC/api $DOCS_WC/javahl
  

  更新索引頁 docs/index.html#api 上的 API 文件連結。

在發行日期提交對「發布」的修改（或從「登台」合併到「發布」）。

1.x.0 發行的新聞稿 ¶

新的次要版本（編號為 1.x.0）可能會附有新聞稿。潛在新聞稿的所有詳細資訊都由 private@ 清單處理，並與 press@a.o 協調。

根據經驗法則，在浸泡開始時於 private@ / press@ 啟動執行緒；讓 press@ 有過長的預警時間會比過短的時間來得好。

宣布發行 ¶

撰寫發行公告，參考先前的公告以取得指導。請記得在公告中包含 URL 和檢查碼！release.py write-announcement 子指令會建立範本公告，可以針對特定情況自訂。如果發行修正了安全性問題，請傳遞 --security 旗標，以在輸出中產生正確的主旨、副本和說明。

如果此發行變更了社群支援等級，務必在使用 release.py 產生公告之前更新 release.py 中的 recommended_release 變數。

從您的 @apache.org 電子郵件地址發送公告。（如果從任何其他地址發送，寄往 announce@ 的郵件將會反彈。為獲得最佳效果，請遵循 提交者電子郵件 頁面上的說明，並透過官方郵件中繼器傳送您的訊息。）請確保您的郵件程式不會將網址換行到多行。

注意：我們會在宣布版本之前更新網站，以確保版本公告中的所有連結都是有效的。在宣布版本之後，會將連結加入到版本公告電子郵件中，並新增到網站。

有兩個 announce@ 郵件清單會張貼版本公告：Subversion 專案的 announce@subversion.apache.org 清單，以及 ASF 全體的 announce@apache.org 清單。您傳送給 ASF 全體的 announce@ 清單的訊息可能會遭到拒絕。這會產生一則管理通知，其主旨行如下：Returned post for announce@apache.org。要求郵件清單軟體拒絕訊息的管理員可能會忽略在拒絕訊息上簽名，讓拒絕訊息變成匿名，而且拒絕的理由可能是無效的。無論如何，請保持冷靜，並將拒絕訊息轉寄到 dev@ 郵件清單，以便專案可以討論是否需要對此採取任何措施。（如有必要，可以透過 announce-owner@ 處理程序聯絡 announce@ 郵件清單管理員。）

更新各種 Subversion 相關 IRC 頻道中的主題，例如 libera.chat 上的 #svn 和 #svn-dev。

如果這是 X.Y.0 版本，請更新已變更支援狀態的任何分支的 STATUS 檔案最上方的社群支援等級。這通常會是 X.Y.x/STATUS、X.$((Y-1)).x/STATUS，如果新版本是 LTS 版本，則也會是支援最久的 LTS 分支的 STATUS 檔案。

在網站中加入連結到版本公告電子郵件 ¶

更新 ^/subversion/site/publish/news.html 和 ^/subversion/site/publish/index.html，取消註解並加入連結到版本公告電子郵件。

使用 release.py 的自動化程序 ¶

建立版本分支的大部分工作都可以透過 tools/dist/release.py 自動化

在一個幾乎是空的目錄中執行此命令，它會進行一些暫時的結帳

release.py --verbose create-release-branch A.B.0

如果先前未執行，請為專案網站建立版本說明範本

release.py --verbose write-release-notes A.B.0 > .../docs/release-notes/A.B.html
svn add .../docs/release-notes/A.B.html
svn ci -m "Add release notes template." .../docs/release-notes/A.B.html

手動程序 ¶

本節的大部分步驟都可以透過 tools/dist/release.py 自動化—見上文—但在此記載以防版本管理員想要手動執行

• 使用伺服器端副本建立新的版本分支

        svn cp ^/subversion/trunk \
               ^/subversion/branches/A.B.x \
               -m "Create the A.B.x release branch."
      

• 編輯主幹上的 subversion/include/svn_version.h，並增加其中的版本號碼。請勿提交這些變更。

  主幹上的版本號碼總是反映您剛建立分支的後一個主要/次要版本（例如 2.0.x 分支為 2.1.0，1.3.x 分支為 1.4.0）。

• 編輯 subversion/bindings/javahl/src/org/apache/subversion/javahl/NativeResources.java，並增加 SVN_VER_MINOR。請勿提交這些變更。

• 編輯 subversion/tests/cmdline/svntest/main.py，並增加 SVN_VER_MINOR。請勿提交這些變更。

• 編輯 CHANGES，如果尚未新增，請為即將推出的版本新增一個新區段，並為未來要推出的次要版本新增一個新區段。每個區段都以

        Version A.B.0
        (?? ??? 20XX, from /branches/A.B.x)
        https://svn.apache.org/repos/asf/subversion/tags/A.B.0
      

  目前先將發布日期留白。在正式推出前都會維持此狀態。

• 提交這些變更，並附上類似以下的記錄訊息

        Increment the trunk version number to A.$((B+1)), and introduce a new CHANGES
        section, following the creation of the A.B.x release branch.
  
        * subversion/include/svn_version.h,
          subversion/bindings/javahl/src/org/apache/subversion/javahl/NativeResources.java,
          subversion/tests/cmdline/svntest/main.py
            (SVN_VER_MINOR): Increment to $((B+1)).
  
        * CHANGES: New section for A.$((B+1)).0.
      

• 在發行分支中建立一個新的 STATUS 檔案。

• 確保所有 Buildbot 建置器都建置新的發行分支。

  將 A.B 新增到 https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/subversion.conf 中的 MINOR_LINES 清單。

• 建立一個範本發行說明文件 site/publish/docs/release-notes/A.B.html