本文档描述了 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 是我们社区中一项非常重要的工作，因为制作稳定版本需要相当长的时间。如果您感到幸运，可以发布版本而无需测试，但我们的经验表明，这会导致更多失败版本。总的来说，我们的经验表明，协调良好的发布比非协调发布效果更好。在所有情况下，发布候选版本被指定为发布需要三个 +1 票，并且 PMC 成员的 +1 票多于 -1 票。
一般来说，当自上次发布以来应用了一些有用的更改，并且没有待解决的重大问题时。我们的惯例是在存储库的 STATUS 文件中指示重大问题。重大问题条目并不意味着无法发布版本——它更多地表明当前项目的共识，以及对关键路径上需要解决哪些修复的提醒。每个 RM 都可以根据当前 Subversion 的内容选择何时发布候选版本。整个 PMC 可以决定该候选版本是否值得发布。
在 STATUS 中被标记为重大问题的项目表明有人认为必须在下次发布之前解决该问题，并且 RM 将会等到它被解决或从重大问题类别中移除。这些项目可能是错误、尚未解决的未决否决或必须包含在发布中的增强功能。请注意，RM 也可以添加重大问题条目，以表明哪些问题必须在他们个人愿意发布候选版本之前解决，尽管他们无法阻止其他人接任 RM 工作并提议他们自己的发布候选版本。
RM 拥有的唯一权力是决定当前 Subversion 的内容是否值得他们为发布候选版本付出努力。RM 唯一有权处理的是基于我们 Subversion 的内容构建源代码包，然后可以将其提交投票。他们可以决定为候选版本标记哪个快照修订版。他们可以决定提前分支并在分支而不是更活跃的开发树上构建候选版本，但他们无法阻止其他人也使用该分支。他们还可以决定根本不构建任何东西。他们可以进行各种组织支持、宣传、辩护或其他任何事情，以鼓励项目的其他提交者应用更改、测试候选版本、对问题进行投票等。
RM 不是独裁者（无论是否仁慈）。他们没有权利拆解或选择他们可能想要发布的任何产品变体：它必须是存在于我们的 Subversion 中并适用于目标版本号的特定标签或修订版（时间点）。如果他们在树中发现他们不喜欢的东西，那么他们与其他 PMC 成员拥有相同的权利，可以先更改或否决该代码，将更改应用于 Subversion，然后构建发布候选版本。同样，RM 无法在候选版本中包含任何被其他人否决的更改，并且如果候选版本包含自构建以来被否决的任何更改，则无法发布。如果 RM 在发布过程中了解到某些信息，他们认为出于任何原因导致构建无法发布，则他们有权取消自己的候选版本。但 RM 无法阻止 PMC 中的任何其他人使用相同的候选版本，并在他们自己的管理下作为 RM 呼吁发布该候选版本。
RM 可以对发布候选版本执行健全性检查。一个强烈推荐的建议是对候选版本运行 httpd-test 套件。发布候选版本应该通过所有相关的测试，然后才能正式发布，并且肯定要避免新的回归（以前通过的测试，现在失败了）。
另一个好主意是在 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（您可以指定要使用的签名 ID）。
生成提议的发布公告和 CHANGES 条目。
将生成的 tarball、签名和提议的公告提交到 Subversion。https://dist.apache.org/repos/dist/dev/httpd/ 存储库。
准备并发送电子邮件，主题为 [VOTE] Release X.Y.Z，以呼吁测试和投票该候选版本。将其发送到 [email protected]。
投票结束后，tarball 和签名可以移动到发布分发镜像。
在 Bugzilla 中添加新版本和新模块（如果有）（或要求基础设施团队这样做）。
在镜像复制数据 24 到 48 小时后，可以发布发布公告，以及任何待处理的安全公告。
本地检出：为下一个版本的开发增加补丁号。
本地检出：在 CHANGES 中添加相应的版本占位符。
本地检出：在 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。不要尝试用额外的更改来重载之前的压缩包，只需不断前进。
为了让 ASF 发布候选压缩包/存档，至少需要三位项目成员投票赞成发布，并且赞成票必须多于反对票。发布投票没有“否决权”。如果之前否决的特定代码被错误地包含进来，应该向 RM 指出。在这种情况下，应该重新发布一个不包含该代码的压缩包候选版本。
非提交者可以对发布版本的质量进行投票。事实上，这非常鼓励，因为它为社区提供了关于发布版本质量的宝贵反馈。但是，只有 PMC 成员投出的具有约束力的投票才计入发布版本的指定。
最后，请注意，投票针对的是 *源代码* 压缩包，只有源代码才是权威的。二进制文件虽然有用，但被认为是其他工件，必须从发布版本中包含的精确源代码生成。如果对特定平台的补丁不可避免，则必须将适用的补丁与平台二进制文件一起提供。
请记住，自动化在很大程度上处理了移动和公告。
一旦发布版本达到最高可用指定（由 RM 决定），就可以将其移动到 apache.org 上的 httpd 分发目录。发布压缩包和签名可以从 https://dist.apache.org/repos/dist/dev/httpd/ 存储库使用 svn mv 命令移动到 https://dist.apache.org/repos/dist/release/httpd/ 存储库。在该发布树中，还有 patches/、subproject/ 和 binaries/ 分发树。
应该确保发布版本和任何新模块也添加到 Bugzilla 中，方法是向 [email protected] 发送邮件，请求添加。该请求将在那里由具有 Bugzilla 管理员权限的项目成员之一接收，发布版本将被添加到 Bugzilla 中。在文件移动后大约 24 到 48 小时，可以发布公开公告。我们等待这段时间，以便镜像在公告发布之前收到新版本。然后，可以从您的 apache.org 邮箱地址向公告列表 ([email protected]、[email protected]) 发送电子邮件。公告草稿通常会在发送公告之前发布到开发列表上，以便社区澄清我们认为应该在公告中解决的任何问题。
不要忘记在项目的 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 文件暂存到私有的 SECURITY 存储库中，以便发现问题。
简而言之，不。公开发布所需的唯一文件是源代码压缩包 (.tar.Z、.tar.gz)。志愿者可以提供 Win32 源代码分发版和二进制文件，以及其他特殊二进制文件。
请注意，典型的 Win32 源代码分发版与原始压缩包不同，因为它包含生成的项目文件以及该平台所需的 CRLF 行尾。更多信息可以在这里找到 这里。
在您将暂存的发布版本推送到不同的存储库之前，所有操作都是可逆的。如上所述，您可以运行
../tools/release/reset-candidate.sh
在您的检出版本中。如果脚本无法正确检测版本，您可以提供候选版本作为参数。它会告诉您它找到了什么并将其删除。
然后您可以重新开始。您没有对分支本身提交任何与发布相关的更改。如果您在创建候选版本时使用了“rcN”后缀（应该这样做），只需在下次尝试时增加该数字，就不会有任何混淆。
例如：
reset-candidate.sh 撤消所有更改如果发布版本已经公开，则有两种解决方法
撤回发布版本，并立即创建一个包含该问题修复程序的另一个发布版本。在发布时，补丁号应该已经在您的分支中递增（如果失败，您需要手动执行此操作）。
如果问题不太严重，请将该问题的补丁放在 /dist/httpd/patches/apply_to_X.Y.Z 目录中。发布说明中应该包含指向该目录的链接，以及每个补丁解决的问题的描述。
与往常一样，如果您对我们的流程有任何建议或意见，请随时通过电子邮件将您的意见发送到我们的开发人员邮件列表。我们希望您觉得本文档有用。