1. 简介
本策略文件阐述了 Joomla 用户社区，从普通非技术用户到高级技术开发人员，可以从 Joomla 项目涵盖的产品中期待什么。
这主要关于我们如何处理和管理变化：我们如何在不断变化的技术环境中适应、开发和发展我们的产品；我们如何向用户和贡献者传达对产品在从一个版本到下一个版本的变化的期望；以及我们如何引导贡献者朝着我们作为社区想要的未来变化迈进。
我们项目中的利益相关者有广泛不同的需求，必须在两个极端之间取得平衡：一方面是任何变化都不受欢迎的人，另一方面是那些在持续变化中蓬勃发展的人。如果我们的产品要与目标用户保持相关性，改变是必不可少的，因此我们的目标是以一种最大程度地减少其可能造成的干扰的方式来管理这种改变。
由于 Joomla 项目负责多个产品，因此本策略的编写尽可能通用，并允许将新产品添加到我们的产品组合中，而无需进行任何广泛的重写。
本策略建立在自项目成立以来的许多年来，许多人的大量实践经验之上。这里所写内容背后的原因以及在实现这些目标的过程中所汲取的经验教训，超出了本文件本身的范围，应参考其他来源以获得相关评论。
1.1 执行摘要
本文件必然很长，因为有很多细节需要涵盖，这意味着不幸的是，很多人不会阅读全部内容。认识到这一现实，本节试图总结你需要了解的内容，并引导你到相应的章节以获取更多信息。
以下是本策略的关键要点
- 版本号方案是理解版本中固有变化程度的关键。版本号分为三部分，用点分隔：[主版本].[次版本].[修订版]。例如，2.5.18 的主版本号为 2，次版本号为 5，修订版号为 18。将主版本号递增的版本称为主版本；只将次版本号递增的版本称为次版本；只将修订版号递增的版本称为修订版。有关更多详细信息，请参阅我们的 版本发布策略。
- 如果你的系统在更新到该版本后仍然正常运行，即使你的系统其他部分没有同时更新，那么该版本就被认为与早期版本“向后兼容”。但是，向后兼容性的范围是有限制的，你应该阅读 向后兼容性策略 以获取完整详细信息。
- 主版本是唯一可以有意打破向后兼容性的版本类型。次版本可能会添加新功能和能力，但它必须与它所替换的版本向后兼容。修订版仅用于修复错误和安全漏洞，不会破坏向后兼容性。
- 版本要么受支持，要么不受支持。当我们说一个版本受支持时，我们的意思是所有重大问题和大多数次要问题将在后续版本中得到解决。有关更多信息，请参阅 支持策略。
- 在每个主版本系列中，只有最新的次版本受支持。只要发布了新的次版本，对先前次版本的支持就会结束。
- 主版本系列仅在该系列中最新的次版本发布至少 2 年后才能被声明为生命周期结束（因此不再受支持）。这意味着，每次发布次版本都会重置该系列的支持时钟，从而确保主版本系列只要有足够兴趣生产该系列的次版本，就会享受延长生命周期。
- 始终会有从一个版本升级到任何其他后续版本的受支持路径。通过明确定义升级路径，用户可以更加确信升级成功，开发人员会确切地知道必须测试哪些升级路径。有关完整详细信息，请参阅 升级策略。
- 我们非常重视安全问题，我们有一个专门的团队 JSST，他们审查所有报告的问题，并采取必要的措施来缓解或修复每个已确认的问题。有关更多信息，请参阅 安全策略。
- 我们欢迎个人、合作或企业贡献，这些贡献将增强我们的产品，造福社区。有关完整详细信息，请参阅我们的 贡献者策略。
1.2 愿景
我们的愿景是为数字出版和协作提供灵活的平台。
1.3 目标
为我们当前和未来的用户群提供稳定可靠的平台。
以可管理的方式为用户和开发人员提供创新。
使开发人员能够随时轻松地向项目贡献代码。
1.4 原则
Joomla 努力遵循“以简单实现强大”的口号来进行所有开发工作。为此，我们有五个主要原则，这些原则内在于 Joomla 开发策略，旨在实现我们的目标。
1.4.1 稳定的主分支
对于我们的愿景而言，每个 Joomla 产品主版本的稳定性以及在短时间内准备好发布至关重要。这由我们的 贡献者策略 支持。
1.4.2 可预测的增量软件版本发布
1.4.3 强有力的向后兼容性支持
对于任何软件平台而言，向后兼容性都是重中之重。这由我们的 向后兼容性策略 和我们的 升级策略 支持。
1.4.4 健全的安全策略
这由我们的 安全策略 支持。
1.4.5 开放的开发流程
我们的开发流程旨在对任何希望参与的人开放且易于访问。我们努力创造一个环境，让人们协同工作以解决问题，并将创新、新鲜的理念融入到我们生产的软件中。
2. 贡献者策略
以下是对代码贡献的要求，这些要求必须满足才能考虑将代码贡献纳入 Joomla 产品中。
2.1 编码规范
所有提交合并的代码都必须符合最新的 编码规范。
2.2 自动化测试
自动化测试用于隔离软件的特定部分或功能，并确保它们能够正确运行。所有现有的测试都必须通过才能合并新的代码。
2.3 对所有新的 API 类和方法进行额外测试
添加到 API 的任何新方法或类都必须伴随有效的单元测试，以验证其正确性。这有助于确保不仅当前代码有效，而且未来的更改不会导致主分支不稳定。在适当的情况下，应创建系统测试以验证预期行为。
2.4 对代码库的所有更改和添加进行文档化
添加到代码库的所有类和方法都必须在源代码中包含完整的文档注释，并在 README.md 文件中包含说明性文本。其他要求（例如，最终用户文档要求）可以在 CONTRIBUTING.md 文件中找到。
2.5 对特定 Joomla 产品的额外要求
对 Joomla 产品（例如 CMS）的贡献可能需要满足除上述要求之外的额外要求。例如，这些可能包括帮助屏幕、语言键和可测试的升级路径。有关任何额外要求的完整详细信息，请参阅相应的 CONTRIBUTING.md。
3. 发布政策
发布政策描述了每个版本如何融入整体发布生命周期，并定义了它在该生命周期中必须达到的里程碑。
3.1 软件发布生命周期
软件发布生命周期由不同的阶段和里程碑组成，这些阶段和里程碑表达了软件从计划到开发、发布和支持的成熟度。并非所有版本都会经历所有可能的阶段。例如，修补程序版本通常会省略 alpha、beta 和候选版本里程碑。
3.1.1 计划阶段
计划阶段主要包括讨论，很少或根本没有实际软件可用。新功能的想法可能会在开发者邮件列表上发布“请求意见（RFC）”文档时，迈出实现的第一步。RFC是对想法及其潜在实现的讨论，并邀请更广泛的社区参与进一步的讨论、反馈和改进想法。
在计划阶段，可能会生成一些代码片段或概念验证实现，以演示可行性或引出更多反馈并评估想法。
在此阶段发布的版本有时被称为“预 alpha”版本。
3.1.2 开发和测试阶段
在此阶段，软件根据计划积极编写、测试和记录。这可能由生产工作组协调，特别是对于较大的功能，但它也可能是一个个人或小型团队的努力，没有项目协调。
在此阶段发布的版本将被标记为“alpha”、“beta”和“候选版本”。
虽然在此阶段发布的版本可能带有版本号，但这些版本号在软件进入发布阶段之前可能会发生变化。
3.1.3 发布阶段
当第一个“通用可用性”版本可用时，软件进入发布阶段。 在此阶段，代码被认为是生产质量的，适合一般用户使用。
此阶段的版本受版本编号方案的约束，该方案要求语义版本控制，如 3.3 版本编号 中所述。
3.2 软件里程碑
Joomla 发布生命周期中有四个里程碑：alpha、beta、候选版本和通用可用性。
3.2.1 Alpha
alpha 里程碑表示软件中存在可供测试的新技术，但软件尚未功能完整。alpha 软件还可用于演示功能的可能组合，以查看它们是否能够成功地协同工作。某些功能可能会在以后的里程碑中移除。
alpha 版本的目标受众是开发社区，包括可能受到核心更改或新功能影响的第三方开发者。
alpha 软件不适合生产环境。
3.2.2 Beta
beta 里程碑被认为功能完整，但仍被认为不适合生产环境。软件旨在彻底测试回归、安全性和稳定性问题。
第三方扩展开发者应该针对所有 beta 版本测试他们的产品，并在问题跟踪器中报告任何问题。等到候选版本发布已经太迟了。
3.2.3 候选版本 (RC)
候选版本的目的是测试最终的打包和发布过程，以确保一切准备就绪，以便软件能够通过第一个通用可用性版本进入发布阶段。
重要的是，第三方扩展开发者对所有候选版本进行最终测试，并立即报告任何错误。但是，只有涉及核心软件或包含的扩展的重大“阻碍程序”错误将在候选版本中修复。仅影响第三方软件的问题不会在此阶段修复。不会添加或删除任何功能。最终的版本号已确定。
候选版本被认为是完整的，适合生产环境，但是只有了解风险的专业人士才能将其部署到生产环境中。候选版本有可能被重新标记为通用可用性版本，除非出现严重问题。
3.2.4 通用可用性 (GA)
通用可用性里程碑表示该版本非常稳定，适合最终用户。
3.3. 版本编号
软件发布是软件代码、文档和支持材料的发布。每个版本都带有版本标识符，该标识符的结构旨在让读者了解它与其他版本的关联方式。
Joomla 严格遵循 语义版本控制 (2.0.0)，本文件也使用其中定义的术语。
总之，Joomla 的版本标识符遵循三级数字约定，其中级别由更改的重要性定义。
major.minor[.patch]
其中
- 主版本标识符的递增表示向后兼容性的中断。
- 次版本标识符的递增表示添加了新功能或对现有功能进行了重大更改。
- 修补程序版本标识符的递增表示已修复错误。
有关完整详细信息，请参阅 SemVer 文档。有关构成我们产品中向后兼容性的内容的更多信息，请参阅 向后兼容性。
4. 支持政策
对 Joomla 项目正式发布的软件的支持受本支持政策的约束，该政策规定了您对每个软件版本的错误和安全修复可以期待什么。总之，仅支持一个主要系列中的最新次要版本。在至少两年支持且没有进一步的次要版本后，代码可能被声明为生命周期结束，因此不受支持。
4.1 问题严重性
所有软件都包含错误，但不同的错误在发现时会引发不同的响应级别，具体取决于报告的严重性。错误（通常称为问题）根据以下等级进行分类
| 优先级 | 描述 | |
|---|---|---|
| P1 | 重大 | 导致软件停止运行的问题（例如 PHP 错误）或被归类为“严重”或“高”的安全问题。 |
| P2 | 高 | 严重阻碍软件运行的问题（例如 PHP 通知、速度缓慢）或被归类为“中等”或“低”的安全问题。 |
| P3 | 正常 | 正常错误。 |
| P4 | 低 | 低级别错误或恼人之处。 |
有关安全级别的定义，请参阅 安全政策。
4.2 支持定义
当发布受到支持时，这意味着所有 P1 和 P2 错误以及大多数 P3 和 P4 错误都将得到应有的考虑并随后得到解决。这通常是通过发布修补程序版本来实现的，但在某些情况下，问题可能在下一个次要版本或主要版本中解决。
对于 CMS，每当发布新版本时，都会有一条受支持的升级路径。请参阅 升级政策。
4.3 支持的版本
软件经历了开发、发布、改进和支持的生命周期。这四个步骤处于不断发展状态，直到软件达到宣布的 EOL（生命周期结束）。所有主要版本都将从其最初发布日期起具有 4 年或更长的预计生命周期。确定主要版本将支持多长时间会考虑其首次发布日期、其发布路线图以及以下因素。
- 主要系列将有一个不低于 2 年的初始活跃开发周期，紧随其后是 2 年的支持周期。活跃开发周期内的次要版本不会影响 EOL（生命周期结束）。（可预测的 EOL）
- 在最初的 2 年活跃开发周期内，主要系列将有一个里程碑路线图。在活跃开发周期结束时，主要系列的路线图可能会变成未来次要版本发布日期的估计日历（如果适用）。
- 在最初的活跃开发周期之后，每个新的次要版本发布都会将主要系列的 2 年支持周期重置。初始活跃开发周期后的次要版本将影响生命周期结束日期。（估计的 EOL）
- 最新次要版本是该主要系列中唯一受支持的版本。
- 当一个次要版本被同一主要系列中的新次要版本取代时，对该次要版本的支持立即结束。（例如：3.3 的支持将在 3.4 发布后立即结束。）
- 生产部门领导层将提前至少 6 个月通知主要系列中估计的最后一次次要版本发布。此通知将作为路线图的一部分，成为最终次要版本发布的软目标日期。
- 主要系列的最终 EOL（生命周期结束）公告将在主要系列的最后一个次要版本发布后 18 个月发布。此时，您将有 6 个月的支持时间，直到主要系列达到 EOL 并且不再受支持。
4.3.1 主要版本的可预测 EOL（生命周期结束）
在最初的 2 年活跃开发周期内，所有主要版本都将有一个可预测的 EOL（生命周期结束）日期。此期间的次要版本不会影响生命周期结束日期。
4.3.2 主要版本的估计 EOL（生命周期结束）
在主要版本的初始活跃开发周期结束后，每个新的次要版本发布都将继续重置 2 年的支持周期。当主要版本超出其活跃开发周期时，EOL（生命周期结束）日期将变成估计日期。次要版本可能会无限期地继续发布。
请参阅主要版本的路线图，以了解初始活跃开发周期结束后次要版本的发布。主要版本的路线图可能有助于确定计划的未来次要版本发布及其时间范围（如果适用）。
4.3.3 主要版本的 EOL（生命周期结束）公告
将发布 EOL（生命周期结束），以便至少提前 6 个月通知主要版本将达到生命周期结束。在生产部门领导层的酌情决定下，支持期可以无限期地延长，超出最初的次要版本 2 年期限。所有被宣布为 EOL（生命周期结束）的主要版本将不再由 Joomla 项目维护其稳定性或安全问题。更广泛的社区可能会继续对任何不受支持的软件提供非官方支持，但 Joomla 项目没有义务以任何方式协助此类支持。
4.3.4 次要版本的修补程序版本
修补程序版本不会重置支持周期，也不会影响预计的 EOL（生命周期结束）日期。
4.3.5 示例
- 版本 4.0 发布，最初将获得 2 年的支持期限，加上从其发布日期起在其初始开发生命周期中剩余的 2 年。
- 4.1 版本在 4.0 版本发布 2 个月后发布。4.0 版本将不再受支持，4.1 版本将成为受支持版本。
- 即使 4.1 是 2 年活跃开发周期中发布的唯一一个次要版本，生命周期结束日期也不会改变。
- 4.8 版本是在 4.0 版本的初始主要版本发布后 2 年 10 个月发布的。
- 4.8 版本比最初 2 年的活跃开发周期晚了 10 个月。
- 4.8 版本将从该次要版本发布之日起获得 2 年的支持。
- 从 4.0 版本的初始发布到预计的生命周期结束，4.0 版本的主要版本总共具有 4 年 10 个月的支持发布周期。
主要版本 EOL（生命周期结束）示例图表，时间范围夸大。
| 发布日期 | {主要} . {次要} | 剩余开发周期 | 主要版本 EOL（生命周期结束） |
|---|---|---|---|
| 2015 年 1 月 | 4.0 | 2 年 | 2019 年 1 月（可预测） |
| 2015 年 3 月 | 4.1 | 22 个月 | 2019 年 1 月（可预测） |
| 2015 年 12 月 | 4.2 | 13 个月 | 2019 年 1 月（可预测） |
| 2016 年 5 月 | 5.0 | 2 年 | 2020 年 5 月（可预测） |
| 2016 年 12 月 | 4.3 | 1 个月 | 2019 年 1 月（可预测） |
| 2017 年 9 月 | 4.4 | 0 | 2019 年 9 月（估计） |
| 2017 年 12 月 | 5.1 | 17 个月 | 2020 年 5 月（可预测） |
| 2018 年 3 月 | 4.5 | 0 | 2020 年 3 月（估计） |
| 2018 年 6 月 | 5.2 | 11 个月 | 2020 年 5 月（可预测） |
| 2019 年 8 月 | 4.6 | 0 | 2021 年 8 月（估计） |
4.4 开发版本
所有 Alpha、Beta 和候选发布版本（在 SemVer 中定义为“预发布版本”）必须始终被视为不受支持。这些版本很可能包含严重的错误、安全问题、向前和向后兼容性问题、随后撤回的完整功能等等。从开发版本到任何其他版本，将没有受支持的更新或迁移路径。
5. 升级策略
此策略不适用于 Joomla 框架。
从一个版本的软件产品升级到任何后续版本的目标始终是使其尽可能简单和无痛。但是，由于从一个任意版本直接升级到任何其他任意版本并不现实，因此本策略规定了将受支持的最小升级路径。
拥有此受支持的升级路径很重要，因为此路径的测试应在任何新版本的开发过程中进行，并将成为代码验收的必要条件。第三方扩展开发人员还应注意，这是受支持的升级路径，以便他们可以确保他们的产品也可以沿着相同的路径升级/迁移。
当代码、数据或底层平台（例如 PHP 或 MySQL）中存在重大向后兼容性中断时，升级将变为迁移，这使得“就地”升级站点变得困难或不可能。相反，需要安装具有最新软件的新站点，可能在更新的平台上。然后将数据、配置信息以及可能的一些软件复制到较新的站点，并应用任何必要的转换。
虽然理想情况下，迁移应该是简单的“一键式”操作，但由于兼容性中断，它们要复杂得多，并且用户可能需要按照一系列手动步骤才能成功迁移站点。
总之，受支持的升级路径始终是先升级到当前正在使用的主要系列中的当前已完全修补的次要版本，然后迁移到下一个顺序主要系列中的最新已完全修补的次要版本。
5.1 修补版本
修补版本必须能够通过自动过程应用，并且成功率很高。
到下一个顺序次要版本或主要版本的受支持升级路径假定已应用当前已安装的次要系列中的所有修补程序。
5.2 次要版本
次要版本应能够通过“一键式”升级过程应用，并且成功率很高。由于可能添加了新功能，因此次要版本也可能引入新的错误，这些错误将在后续的修补程序版本中解决。次要版本可能会降低稳定性，而修补程序版本应始终提高稳定性。因此，次要版本通常应由可以运行后续测试以确保升级成功的人员处理。
到下一个顺序次要版本或主要版本的受支持升级路径假定已应用当前已安装的次要版本的全部修补程序。一旦当前已安装的次要版本已完全修补，就可以将站点升级到下一个顺序次要版本。必须按顺序应用次要版本。例如，当前使用 4.3 版本的站点不能直接升级到 4.6 版本，而不先升级到 4.4 版本，然后再升级到 4.5 版本。当然，这些步骤可以隐藏在用户界面后面，以便用户对此一无所知。
5.3 主要版本
新主要版本的发布实际上会创建一个临时分支，该分支会一直持续到旧分支达到生命周期结束。在两个分支都受支持的期间，受支持的升级/迁移路径将是从旧分支中的当前已完全修补的次要版本迁移到后一个分支中的当前已完全修补的次要版本。如果升级/迁移不是到下一个顺序主要版本，则必须分阶段进行升级/迁移，不得省略中间主要版本。
5.4 升级/迁移路径示例
例如，假设当前已完全修补的受支持版本为 4.3.8、5.6.3 和 6.3.5。还假设 4.2 次要版本的最新修补程序为 4.2.18。我们有一个使用 4.2.9 版本的站点，需要迁移到最新的 6.3.5 版本。然后，受支持的升级/迁移路径包括以下一系列单独的升级/迁移步骤：-
1. 应用 4.2.9 到 4.2.18（当前次要系列中的最新修补程序版本）的修补程序。
2. 从 4.2.18 升级到 4.3.8（当前主要系列中的最新次要版本）。
3. 从 4.3.8 迁移到 5.6.3（下一个顺序主要系列中的最新次要版本）。
4. 从 5.6.3 迁移到 6.3.5（最新主要系列中的最新次要版本）。
请注意，从生命周期结束版本进行的迁移，从定义上来说，不受支持。但是，最后一条受支持的迁移路径很可能仍然有效。
6. 向后兼容性策略
Joomla 项目尽可能地保持向后兼容性，并且可以在主要系列内预期完全向后兼容性。只有在启动新的主要系列时才可能破坏向后兼容性。
干净、可维护的代码很重要，但随着时间的推移，保持向后兼容性的需要会使软件更复杂，更难维护。这种技术债务（例如，参见：https://martinfowler.com.cn/bliki/TechnicalDebt.html）只能在新主要系列的第一个版本中解决。
有时，继续开发的最佳方式是放弃对某些元素的支持。这种弃用过程必须谨慎处理，因为它会导致向后兼容性问题。
6.1 适用性
向后兼容性策略只能应用于软件的某些方面，并且重要的是定义这些方面，以便每个人都能清楚地了解该承诺的局限性。通常，向后兼容性适用于（如果适用）：
6.1.1 PHP
/libraries 文件夹中所有未标记为私有的 PHP 代码都被视为 Joomla API 的一部分，并且受向后兼容性约束。将来，这可能会扩展到包括其他 PHP 代码，例如组件类。
6.1.2 JavaScript
所有未标记为私有的 JavaScript 函数和类。
6.1.3 数据库模式
所有数据库模式更改必须伴随一个转换脚本，该脚本可以执行以无损地将旧模式转换为新模式。
6.1.4 XML 模式
添加新实体和属性通常是可以接受的；更改或删除它们是不允许的。
6.1.5 JSON 模式
添加新实体通常是可以接受的；更改或删除它们是不允许的。
6.1.6 语言键
更改或删除语言键被认为是向后兼容性中断。添加新的语言键是可以的。实质性地改变与语言键相关的含义是一种兼容性中断。为了更准确地描述或进行正确的 en-GB 语法而对某些内容进行改写是可以的。
6.1.7 渲染的标记
目前，渲染的标记不受我们的向后兼容性承诺的约束。我们会尽量避免以可能导致站点渲染不同的方式更改标记，但我们无法保证目前不会破坏任何东西。我们将努力定义一些方法，以便将来可以对标记做出向后兼容性承诺，但目前我们尚未就可行的标准达成满意的共识。
6.1.8 URL
对以前提供 200 状态码的 URL 进行任何更改，会导致返回 404（或其他错误）状态码，都属于破坏向后兼容性。但是，如果更改导致重定向到新的 URL（返回 200 状态码），则可以接受。
通常，如果更改了 URL，只要新的 URL 以相同的方式传递并渲染完全相同的资源，那么这就不被视为破坏向后兼容性。例如，更改 URL 查询部分中参数的顺序不被视为破坏。
各个产品可能具有除上述之外的向后兼容性约束。这些将在相应的 README.md 中记录。
6.2 弃用
可以在新的次要版本或新的主要版本的第一个版本中将某个元素标记为已弃用。必须在文档中添加有关如何修改当前使用已标记为已弃用元素的代码的建议。
以前已弃用的元素，如果不再在产品本身中使用，则必须在新主要系列的第一个版本中删除，但不能在次要版本或修补程序版本中删除。
例如，在 10.1 版本中已弃用的代码计划在 11.0.0 版本中删除。在 11.0.0 版本中已弃用的代码，不能在 12.0.0 版本发布之前删除。
已弃用的代码将添加 @deprecated 标记到相应的 docblock，并且将在发行说明中注明。
生产部门领导层可以选择推迟删除已弃用元素，如果认为合适的话。
6.3 回归
毫无疑问，版本偶尔会无意中破坏向后兼容性。如果在一个主要系列中发现了一个或多个这样的向后兼容性回归，则将在发现后尽快通过发布修补程序版本来修复它们。
6.4 最低技术要求
最低技术要求（如 PHP 版本、数据库版本等）只能在新的主要版本的第一个版本中提高。
6.5 降级
不支持降级 Joomla 产品。升级过程中产生的更改可能是不可逆的。因此，如果您在升级后遇到问题，应从升级之前立即创建的备份副本中恢复。
不支持降级 Joomla 产品依赖的元素。例如，将产品迁移到具有较低版本 Web 服务器、数据库引擎或 PHP 的新主机时，通常情况下，只要依赖元素仍在产品的最低要求范围内，就可以正常工作，但不能保证，因为在某些情况下，产品使用的数据可能依赖于依赖元素的某些不可逆转的属性。例如，降级加密库往往会产生问题。
同样地，也不支持跨依赖元素类型迁移。例如，不支持从 Postgres 迁移到 MySQL 或反之。可能存在能够执行此类迁移的第三方工具，但这些工具不在我们的支持政策范围内。
7. 安全策略
负责实施 Joomla 项目安全策略的开发人员和安全专家团队是 Joomla 安全应急小组 (JSST)。JSST 的职责是调查和响应已报告的核心漏洞，在软件发布之前执行核心代码审查，在安全问题方面提供公开存在，并帮助公众更好地了解 Joomla 安全问题。
7.1 安全公告
Joomla 是 oCERT 的成员（与许多其他重视安全的软件公司和组织一起）。那些报告安全问题的人可以通过 oCERT 或直接向 JSST 报告，但无论哪种方式，JSST 都将尽合理努力在 oCERT 指南范围内工作。
7.2 公开回应
我们感谢人们发现并报告安全问题的努力，但我们鼓励报告者在 Joomla 发布软件的修补版本之前保留信息。这样做的人将在正式漏洞报告中获得认可。
该项目不会公开概念证明信息来演示漏洞，并鼓励报告者也这样做。如果报告者强烈认为应该发布概念证明说明，则鼓励他们至少在软件修补版本发布后的额外 4 周内保留该信息。
JSST 将根据出版商的要求，回答问题和/或验证任何与 Joomla 安全相关的文章。
7.3 安全发布
除非威胁级别另有规定，否则安全补丁将根据 oCERT 指南和最佳实践，并入软件的下一个可用版本。
7.4 漏洞威胁级别
有两个主要细节会影响漏洞的优先级或“威胁级别”：影响和严重程度。以下表格提供了关于如何评估漏洞的通用指南。在实践中，将针对每个漏洞评估其潜在损害，并相应地进行排名。
7.4.1 影响
| 级别 | 描述 |
|---|---|
| 严重 | “0 天”攻击，以及攻击者可以控制网站的攻击（允许攻击者接管网站）。 |
| 高 | SQL 注入攻击、远程文件包含攻击以及其他导致网站数据泄露的攻击媒介。 |
| 中等 | 跨站脚本攻击、写入 ACL 违规（在不允许的情况下编辑或创建内容）。 |
| 低 | 读取 ACL 违规（在不允许的情况下读取内容）。 |
7.4.2 严重程度
| 级别 | 描述 | 发布修复 |
|---|---|---|
| 严重 | 执行起来非常容易。不依赖任何外部信息（真正的 0 天攻击）。 | 尽快 |
| 高 | 执行起来比较容易。可能依赖于容易获得的外部信息。 | 根据 oCERT 指南 |
| 中等 | 执行起来不容易。可能依赖于敏感信息。 | 根据 oCERT 指南 |
| 低 | 执行起来很困难。依赖于敏感信息或需要特殊情况才能执行。 | 根据 oCERT 指南 |
附录 A：示例生命周期
以下提供了一个示例，帮助您理解整个过程的工作原理
| 日期 | 发布说明 |
|---|---|
| 3.3.0 | 新的小版本；包含新功能。 |
| 3.3.1 至 3.3.7 | 七个修补程序版本，每月修复一次错误；没有新功能。 |
| 3.4.0 | 合并了新功能以及几个错误修补程序；触发新的次要版本发布。 |
| 3.4.1 至 3.4.3 | 大约两个月发布一次错误修复版本。 |
| 3.4.4 | 3.4.3 发布后两天发布关键安全修复程序 |
| 3.5.0 | 新功能已准备就绪并合并；在 3.4.3 发布后大约一个月发布 |
| 3.5.1 至 3.5.2 | 错误修复版本。 |
| 4.0.0-Alpha1 | 团队正在开发新功能，破坏了与 **3.x** 的兼容性。触发了主版本递增；alpha 过程开始。 |
| 3.5.3 至 3.5.7 | 错误修复版本 |
| 4.0.0-Beta1 至 4.0.0-Beta4 | 4.0 版本的功能完整测试版本 |
| 3.5.8 | 3.5 继续修复错误 |
| 4.0.0-RC's 至 4.0.0-GA | 发布候选版本通过最终测试，并发布了 4.0-GA |
| 3.5.9 | 错误修复版本。 |
| 4.0.1 至 4.0.3 | 新主版本发布后不可避免的错误群。 |
| 4.1.0 | **4.x** 系列中的新功能；触发次要版本递增。 |
| 4.1.1 至 4.1.9 | 定期发布错误修复版本。 |
| 4.2.0 | 合并了新功能以及一些错误和低优先级安全修复程序。 |
| 3.6.0 | 为 **3.x** 发布了一些次要新功能 |
| 4.3 至 4.7 | 在一段时间内发布了许多新功能。 |
| 3.6.1 | 次要错误修复；生产部门领导层发现对 **3.x** 系列的兴趣明显下降；宣布下一个 **3.x** 的次要版本将进入长期支持 |
| 4.8.0 | **4.x** 的新功能 |
| 3.7.0 | LTS 版本发布；没有新功能；仅提供安全和重大错误支持。 |
| 4.9.0 | **4.x** 的新功能 |
| 3.7.1 和 4.9.1 | 针对 **3.x** 和 **4.x** 版本中漏洞的安全补丁。 |
| ... | 时间流逝 |
| 3.7.4 | 在 3.7.0 发布 18 个月后发布；技术支持在接下来的六个月内继续，但没有问题需要关注；软件在 3.7.0 发布两年后达到生命周期结束。 |
文档修订历史记录
2014 年 3 月 13 日 - 正式获得生产领导团队批准采用。