此页面记录了 ASF 关于软件发布的政策。本文档适用于 ASF 发布经理和PMC成员。还提供了最终用户的信息。
本文档总结了发布流程。
一般来说，发布是指发布到其所有者群体之外的任何内容。对于 Apache 项目，这意味着任何发布到开发社区之外的内容，开发社区定义为积极参与开发或关注开发列表的个人。
更具体地说，正式的 Apache 发布是指已由 PMC 认可为“基金会行为”的发布。
每个 PMC 必须遵守 ASF 批准任何发布的要求。
有关投票的一般信息，请参阅ASF 投票流程页面。
要使发布投票通过，必须至少投 3 张肯定的约束性投票，并且肯定的约束性投票必须多于否定的约束性投票。发布不得被否决。PMC 成员投的票是约束性的，但是，强烈鼓励非约束性投票，并且是项目健康的标志。有关构成肯定和否定投票的详细信息，请参阅表达投票。
在投 +1 约束性投票之前，个人必须将所有签名的源代码包下载到自己的硬件上，验证它们是否满足下面描述的 ASF 发布政策的所有要求，验证所有加密签名，按提供的说明进行编译，并在自己的平台上测试结果。
发布投票应至少保持开放 72 小时。
项目应发布正式版本，并且不得在开发社区之外发布未发布的材料。
在开发软件和准备发布的过程中，各种包可供开发社区用于测试目的。项目必须将外部人员引导到正式版本，而不是原始源代码存储库、夜间构建、快照、发布候选版本或任何其他类似的包。项目应提供开发人员资源来支持积极参与开发或关注开发列表的个人，从而了解未发布材料的条件。
每个 ASF 发布必须包含一个或多个源代码包，这些包必须足以让用户构建和测试发布，前提是他们可以访问相应的平台和工具。源代码发布不应包含编译后的代码。
所有提供的包必须使用分离签名进行加密签名。它必须由发布经理或自动发布基础设施签名，其中底层实现必须遵循 Apache 安全团队概述的原则。所有提供的包必须使用分离签名。那些投票 +1 发布的人员可以在发布前（根据发布经理的酌情决定）提供他们自己的加密签名以与分离签名文件连接。
Apache 软件基金会生产开源软件。所有发布都以源材料的形式提供，这些材料是进行正在发布的软件更改所必需的。
为了方便可能没有适当工具来构建源代码的编译版本的用户的便利性，可以在正式的 Apache 发布 alongside 旁边分发二进制/字节码包。在所有此类情况下，二进制/字节码包必须与源代码发布具有相同的版本号，并且必须仅添加作为编译该版本源代码发布及其依赖项的结果的二进制/字节码文件。
每个 ASF 发布必须符合 ASF 许可政策。此要求至关重要，并且在创建任何完整版本之前应进行审核。特别是，每个分发的工件都必须仅包含根据Apache 许可政策适当地许可的代码。
每个包都必须提供一个 LICENSE 文件和一个 NOTICE 文件，这些文件说明了包的确切内容。LICENSE 和 NOTICE 不得提供有关未捆绑在包中的材料（例如单独下载的依赖项）的不必要信息。
对于源代码包，LICENSE 和 NOTICE 必须位于分发的根目录中。对于其他包，它们必须位于分发格式中用于许可证材料的习惯位置，例如 Java“jar”文件的 META-INF 目录。
LICENSE 文件¶LICENSE 文件必须包含Apache 许可证 2.0的全文。
当包捆绑多个许可证下的代码时，LICENSE 文件必须包含所有这些许可证的详细信息。对于每个未经 Apache 许可的组件，必须将该组件的详细信息附加到 LICENSE 文件中。组件许可证本身必须附加或存储在包中的其他位置，并从 LICENSE 文件中指向它，例如，如果许可证很长。
NOTICE 文件¶NOTICE 文件必须符合Apache 许可政策的要求。
另请参阅 Apache 许可证 2.0 的第 4(d) 节。
由版权所有者或所有者代理人直接提交给 ASF 的作品组成的源文件必须包含相应的ASF 许可证头。
发布获批准后，所有工件必须上传到规范的 Apache 分发通道 downloads.apache.org 中的项目子目录中。
PMC 负责项目分发目录，并且必须能够说明其所有内容。目录中的所有发布工件都必须由提交者（最好是 PMC 成员）签名。
上传到规范分发通道后，项目（或任何其他人）可以根据其许可证通过其他渠道重新分发工件。
所有正式版本都必须永久存档在 archive.apache.org 上。
（上传到规范分发通道满足此要求，因为归档会作为副作用自动发生。）
项目必须通知董事会任何偏离推荐或要求的政策指令的情况。
发布政策的更改必须得到法律事务部门的批准。
正式化其他正式政策并从本政策中引用它们
在 Apache 等志愿者责任限制组织实践的传统开源开发方法中，有必要在代表“进行中”作品的公共资源和适合公众广泛使用的作品之间做出明确区分。明确界限的目的是为了告知我们的法律策略，为参与发布作品的正式参与者提供保护，如下一节所定义。进行中的资产被视为受控分发，专为自我识别参与项目开发的参与者设计，这些人主要关注项目的开发列表。不受控的分发，即发布，是本策略文档旨在涵盖的内容。
如果我们避免做出这种区分，而是鼓励用户直接与源代码控制或夜间构建进行交互，那么组织将很难为 Apache 提交者和 PMC 成员提供法律保护，这些提交者和 PMC 成员仅在修改软件时行使了自己的判断，而没有获得**授权的业务决策**批准将这些工件按原样分发给公众。Apache 大部分的“官僚主义”和项目治理结构都是为了促进本策略的目标，因此这份文档值得仔细研究。
偏离本策略可能会对法律保护的有效性或 Apache 为保护高级管理人员和董事而支付的保险费产生不利影响，因此强烈建议在未经事先明确的董事会批准的情况下不要偏离。但是请注意，在组织上，我们更偏好稳健、可审查的决策而不是高效的决策，因此，如果您正在考虑向董事会提出替代流程，请确保您的目标反映了这一点。
根据定义，发布是指发布到拥有该作品的群体之外的任何内容。在我们的案例中，这意味着任何发布到产品开发列表人员群体之外的发布。如果公众被指示下载某个软件包，则该软件包已被发布。每个 PMC 必须遵守 ASF 关于批准任何发布的要求。您如何标记软件包是一个次要问题，将在下面描述。
在开发软件和准备发布的过程中，各种软件包被提供给开发人员社区以供测试。**不要在项目网站上包含任何可能鼓励非开发人员下载和使用夜间构建、快照、候选版本或任何其他类似软件包的链接。**唯一应该了解此类软件包的人是关注开发列表（或搜索其档案）并因此了解软件包附加条件的人。如果您发现公众正在下载此类测试软件包，请将其删除。
在任何情况下，未经批准的构建都不能替代发布。如果此策略看起来不方便，则更频繁地发布。正确的发布管理是 Apache 软件开发的关键方面。
Apache 软件基金会开发开源软件。所有发布都以源代码材料的形式提供，这些材料是进行软件更改所必需的。在某些情况下，还会生成二进制/字节码软件包，以方便可能没有适当工具来构建编译版源代码的用户。在所有此类情况下，二进制/字节码软件包必须与源代码发布具有相同的版本号，并且只能添加作为编译该版本源代码发布的结果的二进制/字节码文件。
**测试软件包**不是 Apache 发布。所有发布都需要适当的流程和官方批准。测试软件包用于测试正在进行的开发，并且应该只在项目开发列表中讨论。
**夜间构建**只是从 Subversion/Git 主干/分支构建，通常每天一次。这些软件包旨在定期测试构建过程并为自动化测试人员提供用于回归测试的通用构建。它们并非供公众使用。
**候选版本**是指已提议批准为发布但尚未获得项目批准的软件包。这些软件包旨在供开发人员（以及关注开发讨论的用户）测试并向项目反馈他们对软件包质量（与先前版本相比）的意见。在发布批准之前，可能会有多个候选版本。对开发测试不感兴趣的用户应等到正式批准发布后。
**发布**是指已批准供公众发布的软件包，其质量或更改潜力的感知程度各不相同。旨在供非开发人员日常使用的发布通常被称为“稳定”或“通用可用性 (GA)”发布。被认为可供项目外部的测试人员和开发人员使用，但在功能或功能方面可能尚未稳定的发布，通常被称为“测试版”或“不稳定版”。仅代表项目里程碑且仅供项目外部的前沿开发人员使用的发布称为“alpha 版”。
在发布内容位于项目的发布目录（它是downloads.apache.org的子目录）之前，发布不被视为“发布”。除了发布目录外，使用 Maven 或相关构建工具的项目有时会将它们的发布放在repository.apache.org旁边的一些便捷二进制文件旁边。发布目录是必需的，而存储库系统是可选的便利功能。
每个 ASF 发布**必须**包含一个源代码包，该包必须足以让用户构建和测试发布，前提是他们可以访问相应的平台和工具。源代码包必须由发布经理使用分离签名进行加密签名；并且该软件包及其签名必须在投票 +1 发布之前进行测试。投票 +1 发布的人员可以在发布之前提供他们自己的加密签名，将其与分离签名文件连接起来（由发布经理酌情决定）。
请注意，PMC 负责其发布目录（它是downloads.apache.org的子目录）中的所有工件；并且放置在其目录中的所有工件必须由提交者签名，最好由 PMC 成员签名。PMC 还需要确保源代码包足以构建与发布关联的任何二进制工件。
每个 ASF 发布**必须**遵守 ASF 许可政策。此要求至关重要，并且应在创建任何完整发布之前执行审核。特别是，分发的每个工件都必须仅包含适当许可的代码。更多信息可在基金会网站和发布许可常见问题解答中找到。
发布投票如上文发布批准部分所述进行。
在投票 +1 之前，PMC 成员需要下载签名的源代码包，按照提供的说明进行编译，并在他们自己的平台上测试生成的可执行文件，以及验证该软件包是否符合 ASF 发布策略的要求。
请确保在上传新发布后至少等待一小时，然后再更新项目下载页面并发送公告电子邮件。
告知人们新发布的可用性非常重要。公告必须包含指向源代码相关下载页面的链接。至少，应发送电子邮件通知所有相关的邮件列表。许多顶级项目为此目的设有公告列表。还有一个ASF 范围的公告列表，也适用。
请注意，您不能在不使用“apache.org”邮件地址的情况下发布 ASF 范围的公告列表。此外，请确保您已为项目添加了 3-5 行简短描述（因为 announce.AT.apache.DOT.org 列表的大多数订阅者可能不知道 XX 项目是什么）。
建议在公告邮件中添加与 SHA-1 OpenPGP 兼容的签名。请确保您的公钥已上传到著名的 pgp 网站（例如http://pgp.mit.edu/）。此密钥应为用于签署发布的密钥或由该密钥交叉签名的密钥。
请参阅孵化器发布管理指南（草稿）。或者，请参阅任何已建立的 Apache 项目的“如何发布”开发者文档。（作者熟悉此文档，来自本项目）。
严格来说，发布必须在提交者拥有和控制的硬件上进行**验证**。这意味着提交者拥有物理占有权和控制权，并且拥有对该硬件的排他性完全的管理/超级用户访问权限。这是因为只有此类硬件才有资格持有 PGP 私钥，并且应在私钥所在的机器上或与该机器一样受信任的机器上验证发布。
实际上，当发布包含源代码控制标签的档案（例如，tarball 或 zip 文件）之外的任何内容时，验证该档案的唯一实用方法是在本地构建它；手动检查生成的文件（尤其是二进制文件）是不可行的。因此，基本上，“是的”。
注意：此答案指的是从源代码控制标签生成发布工件所使用的流程。它不涉及测试该工件的技术质量。
测试软件包仅供同意参与的开发人员和感兴趣的社区成员使用，因此不应在面向最终用户的页面上托管或链接，也不应使用closer.lua脚本发布。
项目应使用dist存储库的/dev树或repository.apache.org的暂存功能来托管发布的候选版本，以供开发人员测试/投票（在可能正式批准为 GA 发布之前）。
不是候选版本的夜间构建可以托管在ci.apache.org 项目区域，只需提交 INFRA 工单即可。
当前的发布必须通过将它们放在https://downloads.apache.org/下由 ASF 内容分发系统提供服务（请参阅如何上传发布？）。
项目下载页面必须使用closer.lua脚本，而不是直接链接到主 Apache 网站；有关更多详细信息，请参阅创建下载页面的说明。软件的网站文档必须包含指向源代码下载页面的链接。
项目网站（http:// {project}.apache.org）、虚拟机（http:// {project}.zones.apache.org 和 http://{project}-vm.apache.org）以及源代码控制存储库（svn.apache.org 和 Git 存储库）不得用于分发发行版——也就是说，不应从这些位置下载发行版。
所有发行版都归档在http://archive.apache.org/dist/上。
在发行版首次出现在https://downloads.apache.org/上大约一天后，一个自动化流程会将发行版添加到归档中。一旦发行版放置在https://downloads.apache.org/下，它将自动复制到http://archive.apache.org/dist/并永久保留在那里，即使它从https://downloads.apache.org/中删除也是如此。
如果您有（旧版？）从未归档的发行版，请请求基础设施团队将其复制到http://archive.apache.org/dist/。
downloads.apache.org 应包含**当前正在开发的每个分支中的最新发行版**。当某个版本分支的开发停止时，应从项目的下载目录中删除该分支的发行版。
（如果项目使用 svnpubsub，请从https://dist.apache.org/repos/dist/release/<TLP name>/中删除工件。）
例如，如果 Apache Foo 1.2.x 是与 Foo 1.1.a 同系列的较新发行版，则在发布 1.2.x 时应删除 1.1.a。请注意，所有发行版都会自动归档，请参阅如何将旧版发行版移动到归档
如果 Apache Foo 1.2 是一个新分支，并且 1.1 的开发并行继续，则可以接受从/dist提供 1.1.a 和 1.2.x。
通过将您的发行版压缩包提交到https://dist.apache.org/repos/dist/release/存储库的相应子目录（即 TLP 名称）中。我们的同步过程将在 15 分钟内将文件推送到主下载站点。
上传新发行版后，请等待大约一个小时再更新项目下载页面。
存储库目录https://dist.apache.org/repos/dist/release/<TLP name>/仅供正式发行版使用，即 PMC 批准的归档文件（+ 签名、哈希值）。因此，**默认情况下，只有 PMC 成员才能更新 dist/release 目录树**。
如果发布经理不是 PMC 成员，则需要请 PMC 成员进行实际的发行版发布。
PMC 也可以投票让非 PMC 成员更新 dist/release 区域。要设置此功能，请在INFRA JIRA上打开一个 JIRA 票证，并参考 PMC 的投票结果。
https://dist.apache.org/repos/dist/dev/<TLP name>/下还有一个开发区域，可用于开发版发行。例如，快照和发行版候选版本可以存储在这里。需要注意的重要一点是，此目录不会通过 svnpubsub 发布到内容分发系统。它旨在充当发布成为正式版本之前的暂存位置。
项目的所有提交者都可以写入项目的 dist/dev 区域。
如果用于发行版候选版本，则在成功投票后，可以将相应的文件从 dev/ 树移动到 release/ 树以发布它们。
对dist/存储库的提交邮件会发送到您项目的普通邮件列表。
大多数项目可以按照前两个问题中所述分发发行版。但是，可能给内容分发资源带来压力的发行版**必须**与基础设施团队协调。
**注意** 基础设施团队建议将发行版工件的大小保持在 100MB 以下。ASF **不会**托管大于 1GB 的发行版工件。
其他 dist 策略的具体豁免（例如，哪些内容可以通过内容分发系统分发、哪些内容必须或不能通过内容分发系统分发）也需要与基础设施团队协调。
| 类型 | 位置 |
|---|---|
| 每日构建 | ci.apache.org/projects |
| 当前发行版 | downloads.apache.org |
| 旧版发行版 | archive.apache.org/dist |
downloads.apache.org会自动归档。因此，正式发行版的副本已存在于归档中。要将发行版移动到归档，只需删除项目 dist 目录中的副本即可。请记住更新下载页面上的任何链接。
请参阅发布 Maven 发行版指南。
请阅读应用 Apache 许可证 2.0 版，并查看Apache 许可证和Apache 法律页面以获取最新信息。
每个源文件都必须包含相应的 ASF 许可证文本。
简而言之，每个分发版只需要一个许可证副本。此完整许可证文件应放置在分发版的根目录下，文件名为 LICENSE。对于在 ASF 开发的软件，每个源文件只需要包含样板声明。
新许可证允许使用 NOTICE 文件来包含此类归属声明（包括 Apache 归属声明）。请阅读此处。
包含在现有源文件中的任何归属声明都应移动到该文件中。NOTICE 文件必须包含在分发版中，与 LICENSE 文件并排放置。
确保创建的任何新的 NOTICE 文件中都包含标准的 ASF 归属声明。
请阅读此处。
仅产品软件许可证要求的强制性信息。不适用于普通文档。
是的！NOTICE 文件必须包含以下标准 ASF 归属声明
This product includes software developed at
The Apache Software Foundation (/).
注意：不幸的是，2013 年 1 月 30 日（r1440650）之前的此文档版本不正确，因为它们使用了“由...开发”而不是“在...开发”。官方措辞是在2006 年 5 月 24 日董事会会议记录的第 6C 节中确定的。
当工件包含多个许可证下的代码时，LICENSE 文件应包含所有这些许可证的详细信息。对于每个未经 Apache 许可的组件，应将组件的详细信息附加到 LICENSE 文件中。组件许可证本身也可以附加，或者可以存储在工件的其他位置，并从 LICENSE 文件中指向它，例如，如果许可证很长。
此处是一个显示附加许可证的示例。
ASF 发行版通常会与源代码包一起包含其他材料。这些材料可能包括有关发行版的文档，但必须包含 LICENSE 和 NOTICE 文件。如上所述，如果要将这些工件放置在项目的 distribution 目录中，则必须由提交者使用分离签名对其进行签名。
同样，只有这些工件包含 LICENSE 和 NOTICE 文件才能分发。例如，Java 工件格式基于压缩的目录结构，希望分发 jar 文件的项目必须将 LICENSE 和 NOTICE 文件放在 jar 文件内的 META-INF 目录中。
本节中的任何内容都不应取代此处和此处定义的所有发行版必须主要基于签名源代码包的要求。
请访问下载统计信息页面。