這份文件說明 Apache HTTP 伺服器計畫用於建立 httpd-2.4（目前的 Apache 2.x 分支）版本的普遍發行原則。除了投票指南外，此原則可由發行經理進行調整。
在 Apache 2.1 出現後，Apache httpd 計畫採用奇數偶數發行策略，其中開發會以 alpha 和 beta 版本進行，並設定為奇數次要版本，而其一般可用性（穩定）發行則以後續偶數次要版本進行設計。例如 2.1.0-alpha 到 2.1.6-alpha 隨後是 2.1.7-beta 到 2.1.9 beta，並於 2.2.0 一般可用性版本中達到頂點。
技術上來講，由於 Apache 軟體授權 的關係，任何人都可以發行原始碼。但是，只有 Apache HTTP 伺服器計畫的成員（提交者）可以發行指定為 Apache HTTP 伺服器 (httpd) 的版本。其他人必須將其發行版本稱為「Apache」以外的名稱，除非他們取得 Apache 軟體基金會的書面授權。
遵循我們的官方發行原則，我們僅會接受 Apache HTTP 伺服器計畫成員的發行二進制檔案以放入我們的網站。這可以確保我們的二進制檔案可以由計畫的成員支援。其他人可以製作二進制檔案，但我們不會在我們的網站上發布二進制檔案。
版本發布由版本管理者 (以下簡稱 RM) 協調。由於這項工作需要信任、協調開發社群，以及存取 Subversion 的權限，因此只有專案的提交者才能擔任 RM。但並沒有固定的 RM，而且一次可以有多位活躍的 RM。任何提交者都可以建立候選版本，但前提是候選版本必須根據我們對應於目標版本號碼的現行 Subversion 儲存庫的可發布 (未否決) 標記來建立。為了促進溝通，在建立候選版本之前，最好先提醒社群您的計畫發布時程，因為其他一些人員可能正在提交重大的變更 (或撤銷錯誤)。只有打算提議候選版本進行公開發布投票時，才應該建立該候選版本。在 Apache 沒有「私人」版本。
有許多可運用時間的人。成為 RM 在我們的社群中是一項非常重要的工作，因為製作一個穩定版本需要相當多的時間。如果您覺得很幸運，一個版本可以在不進行測試的情況下發布，但我們的經驗已顯示，這會導致更多「失敗」版本。一般而言，我們的經驗已顯示，協調良好的版本比未經協調的版本狀況更好。在所有情況下，一個候選版本都需要獲得三位以上的 PMC 成員的 +1 投票，以及多於 -1 票的 +1 票才能指定為版本。
一般來說，當自上次發布以來已套用一些有用的變更，而且沒有任何待解決的重大問題時。我們慣例在儲存庫中的狀態檔案中指出「重大問題」。重大問題項目並非表示無法發布版本，它比較像是表示目前的專案共識，以及提醒關鍵路徑上有哪些修正事項。每個 RM 都可以在依據 Subversion 的目前內容選擇何時套用候選版本。整個 PMC 將會決定該候選版本是否應予以發布。
在狀態中標記為顯示阻礙的項目表示某人認為問題必須在下次發行前解決且 RM 將會暫停到問題解決或移出顯示阻礙類別後。這些項目可能是 bug、尚未解決的重大否決或必須納入發行的增強功能。請注意，RM 也可能會新增顯示阻礙分錄，以表明必須解決什麼問題後他們才願意親自削減發行候選者，雖然他們不能阻止其他人接下 RM 工作並提出自己的發行候選者。
RM 擁有的唯一權力是決定 subversion 的當前內容是否值得自己削減發行候選者的努力。RM 唯一擁有權限的是建立來源套件，該來源套件根據我們的 subversion 內容建立，然後可以提交投票。他們可以決定將哪個快照版本標記給候選者。他們可以決定提早分岔，並根據分岔而不是較活躍的開發樹建立候選者，但他們不能阻止別人也在該分岔上工作。他們也可以決定什麼都不建立。他們可以執行動員支持、請願、哀求或其他等各種組織支持來鼓勵專案的其他提交人套用變更、測試候選者、對問題中的事物投票等。
RM 不是獨裁者（不論是否仁慈）。他們無權拆解或選擇他們可能希望發行的任何產品變異：它必須是我們 subversion 中存在且適用於特定發行版本號碼的特定標籤或版本（時間點）。如果樹中有些東西他們不喜歡，那麼他們和其他 PMC 成員有相同的權利來變更或首先否決該程式碼、將變更套用到 subversion，然後建立發行候選者。同樣地，RM 不能在候選者中包含任何已被其他人否決的變更，而且如果候選者包含自其建立以來已被否決的任何變更，則不能發布他們的候選者。如果 RM 在發行過程中發現一些事情，他們認為不論基於什麼原因會導致建立不可發布，則他們有權扼殺自己的候選者。但 RM 無法阻止 PMC 的其他任何人接下相同的候選者，並在自己的管理下作為 RM 呼籲發行自己的候選者。
RM 可以在發行候選者上執行健全性檢查。一個強烈建議是對候選者執行 httpd 測試套件。發行候選者應通過所有相關測試後才能使其官方，並絕對避免新的回歸（先前通過而現在失敗的測試）。
另一個好主意是在 apache.org 上協調運行候選版本一段時間。這將需要與基礎設施團隊進行協調。過去，這個團隊希望看到在生產環境中大約 48-72 小時的用法，以證明該版本在實際環境中具有功能性。請注意，在從運行該版本的 apache.org 實例收集到反饋之前，一些提交者可能會選擇不投票發佈。這並非要求（每個提交者都可以制定自己的個人投票準則），但它會產生一種信心，即該版本不會成為爛貨。
一旦 RM 和任何其他利益相關者適當地測試過樹之後，他們應該為潛在的發布「滾動」一個候選 tarball。
這個過程在很大程度上通過 shell 腳本自動化。執行發佈所需的確切命令已經捕獲在其中，因此考慮閱讀腳本和其中的註解，以全面了解該過程。
自動化處理的重點
它會建立一個候選分支，從你在本地提交的分支和版本中建立 ^/httpd/httpd/tags/candidate-$FULL_VERSION。
在候選版本中：確保版權日期反映在 NOTICE 和 docs/manual/style/xsl/common.xsl 檔案中的當前年份。
在候選版本中：提交 include/ap_release.h 中將 AP_SERVER_DEVBUILD_BOOLEAN 變更為 0 的變更。
在候選版本中：升級 docs/manual/style/version.ent 中的 ENTITY httpd.patch。
在候選版本中：執行 ./build.sh all convmap 以確保文件轉換是最新的。
從候選版本的匯出中建立 tarball。以及校驗和檔案。
使用你的 gpg 金鑰簽署 tarball（你可以指定要使用的簽署識別碼）。
產生一個建議的發佈公告和 CHANGES 條目。
將產生的 tarball、簽名和建議的公告提交到 subversion。https://dist.apache.org/repos/dist/dev/httpd/ 儲存庫。
準備一封電子郵件，內容為 [VOTE] Release X.Y.Z 以呼籲對此候選版本進行測試和投票。將此電子郵件發送至 dev@httpd.apache.org。
投票結束後，tarball 和簽名可以移至發佈發行鏡像。
在 bugzilla 中加入新版本和新模組（如果有的話）（或要求基礎設施部門這樣做）。
經過 24 到 48 小時延遲讓鏡像複製數據後，就可以宣布發佈以及任何待處理的安全公告。
本地 checkout：增加修補程式號碼，以便針對下一個發布進行作業。
本地 checkout：在 CHANGES 中加入對應的版本佔位符。
本地 checkout：在 STATUS 檔案中註記標籤日期。
自動化的工作流程是
# Get the tooling
svn co https://svn.apache.org/repos/asf/httpd/dev-tools tools
# Get the branch to release, e.g.
svn co https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x 2.4.x
cd 2.4.x
# Start a candidate 'rc1'
../tools/release/r0-make-candidate.sh rc1
# Generate tarballs, checksums and signatures,
../tools/release/r1-make-tars.sh -s <gpg key id>
# Create the Announcement* and CHANGES* files. Put these and
# the tarballs onto https://dist.apache.org/repos/dist/dev/httpd
# Create a mail proposal in ./dist/mail-vote-$FULL_VERSION.txt
../tools/release/r2-prep-vote.sh
# declare the vote by sending the mail to the dev list
# wait for the results on this
# Should the vote fail, cancel the release candiate with
../tools/release/reset-candidate.sh
# Start again, use 'rc2', 'rc3'...
# Until the vote passes...
# Push the tarballs, CHANGES* etc. to
# https://dist.apache.org/repos/dist/release/httpd
# this will use the version without any rc1 suffix
../tools/release/r3-push-release-tars.sh
# wait for them to reach the mirrors
# add CVE related information and prepare changes to the
# dist release, website, pmc repository and local checkout
# all these changes are local only
../tools/release/r4-stage-release.sh
# NOTE: this is the point of no return
# Commit all staged changes into the repositories
../tools/release/r5-commit-staged-release.sh
# Update Bugzilla (new version and new modules, if any)
# Get instructions on announcement emails and CVEs
# that need to progress to READY in the ASF cveprocess
../tools/release/r6-announce.sh
# you are done.
社群對程式碼的信心決定潛在版本標記為 alpha、beta 或一般可用性 (GA)，候選者就會這樣被選出來。Apache HTTP 伺服器專案對其版本有三個分類
Alpha
Beta
一般可用性 (GA)
Alpha 表示版本並不適合主流使用，或有嚴重問題禁止其使用。分支 x.{odd}.z 開發的最初版本被視為 alpha 品質。
Beta 表示分支 x.{odd}.z 開發接近完成，且很快將作為 x.{even}.0 GA 版本發布。這表示它預期編譯並執行基本任務。但此版本可能有些問題，阻礙它被廣泛採用。
一般可用性 (GA) 表示這個版本是最佳可用版本，並建議用於所有用途。它也表示這個版本取代所有先前的 GA 版本，且其介面在其 x.y 版本的生命週期中都應保持穩定。（處於變動中的那些介面被指定為實驗性質。）
最後，記住版本號碼很便宜。如果 x.y.13 因為缺陷、之前的否決權，或僅僅因為要加入「一次又一次的變更」而撤回；RM 應該指定 x.y.14。不要嘗試用額外的變更過載早期的 tarball，只要繼續前進即可。
ASF 要發布候選 tarball/檔案，至少要有三個專案成員肯定投票發布，而且發布的正面票必須多於反對票。發布投票沒有「否決權」。對特定程式碼的先前否決權可以且應該提報給 RM（如果錯誤包含的話）。如果這是情況，應重新發布一個新的 tarball 候選版本，且不含冒犯性程式碼。
非承諾人可以對版本品質投下贊成票。事實上，這非常受鼓勵，因為它會提供社群急需的版本品質回饋。不過，只有 PMC 成員投下的具約束力票數才算數。
最後，請注意，投票是針對原始碼 tarball，且只有原始碼具有權威性。二進制檔案雖然有幫助，但會被視為其他成品，而且必須由版本中包含的確切原始碼產生而來。如果對特定平台來說，修補程式不可避免，那麼適用的修補程式必須與平台二進制檔案一起提供。
記住，自動化處理這大部分的移轉和公告。
一旦版本達到最高可用指定（RM 視為），這個版本就可以移轉到 apache.org 上的 httpd 發行目錄。可以將發布的 tarball 和簽章從 https://dist.apache.org/repos/dist/dev/httpd/ 儲存庫 SVN mv 到 https://dist.apache.org/repos/dist/release/httpd/ 儲存庫。在該發布樹中也有 patches/、subproject/ 和 binaries/ 發行樹。
應確保發布和任何新模組也會透過寄送電子郵件至 dev@httpd.apache.org 加入 Bugzilla，要求相同作法。由擁有 Bugzilla 管理員權限的專案成員獲得該請求，且該發布將加入 Bugzilla。在檔案移轉的 24 至 48 小時後即可進行公開公告。我們會等待此一段時間，好讓鏡像伺服器能在公告之前收到新發布。然後可以透過你的 apache.org 電子郵件地址，將電子郵件傳送至公告清單 (announce@apache.org，announce@httpd.apache.org)。公告草案通常會在傳送公告之前，張貼至開發清單上，好讓社群釐清我們認為應於公告中探討的任何問題。
別忘了更新專案 doap 檔案 ( httpd/site/trunk/docs/doap.rdf )、索引 ( httpd/site/trunk/content/index.mdtext ) 和下載頁面 ( httpd/site/trunk/content/download.mdtext ) 的版本號，並註明公告日期。下載頁面也有 RM 的名稱和金鑰 ID 可供驗證。這些變更由 CMS 發布。有關更多資訊，請參閱這裡。
如果發布包含任何安全問題的修正程式，則你需要確保已遵循這裡的額外步驟。
此外，你需要更新並加入漏洞 json 檔案至 ( httpd/site/trunk/content/security/json/ )，其中包含所有安全修正程式的詳細資料。提交後，此舉動會自動產生相關的安全頁面。此資訊也可協助產生公告電子郵件。請務必使用 CMS 發布這些頁面更新。
你可能希望在發布之前，將 json 檔案分段置放於私人安全性存放庫中，以便找出問題。
簡短的回答是不。公開發布唯一需要的檔案是原始碼 tarballs (.tar.Z,.tar.gz)。志工可以提供 Win32 原始碼發行版和二進位檔，以及其他生僻的二進位檔。
請注意，典型的 Win32 原始碼發行版與原始 tarball 的不同之處在於，它已產生專案檔案，以及該平台所需的 CRLF 換行符號。有關更多資訊，請參閱這裡。
在你將分段準備好的發布推送到不同存放庫之前，一切都還是可以復原的。依照上述所列，你可以執行
../tools/release/reset-candidate.sh
正在您的檢出版本中。如果指令碼無法正確偵測版本，您可以將候選版本提供為一個引數。指令碼會告訴您它找到並移除的內容。
然後您可以重新開始。您並未提交任何與發行版本相關的變更，回到分支本身。如果您在建立候選版本時使用了「rcN」字尾（正如您應當做的那樣），下次嘗試時只需遞增該數字即可，那樣便不會造成混淆。
此處提供範例說明
reset-candidate.sh 回復所有變更如果發行版本已公開，則有兩種處理方式
撤銷發行版本並立即建立另一個包含該問題修正程式的發行版本。在發布時，您的分支應已遞增修補程式號碼（如果失敗，您需要手動進行此動作）。
如果問題沒那麼嚴重，則將該問題的修補程式放置在 /dist/httpd/patches/apply_to_X.Y.Z 目錄中。發行說明中應包含連結到此目錄，說明每個修補程式解決了哪個問題。
與往常一樣，如果您對我們的流程有任何建議或評論，請隨時以電子郵件將您的意見傳送至我們的開發人員寄件清單。我們希望本文件對您有所幫助。