Joomla! 开发策略 - Joomla! 开发者

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 产品主要版本的 master 分支始终稳定并可在短时间内发布。这得到了我们的贡献者策略的支持。

1.4.2 可预测的增量软件发布

这得到了我们的发布策略和支持策略的支持。

1.4.3 强有力的向后兼容性支持

任何软件平台的向后兼容性都是重中之重。这得到了我们的向后兼容性策略和升级策略的支持。

1.4.4 健全的安全策略

这得到了我们的安全策略的支持。

1.4.5 开放的开发流程

我们的开发流程旨在对任何希望参与的人开放和易于访问。我们努力创造一个环境，让人们共同解决问题，并将创新、新颖的想法融入我们生产的软件中。

2. 贡献者策略

以下是代码贡献才能被考虑纳入 Joomla 产品的最低要求的总结。

2.1 编码规范

所有提交用于合并的代码必须符合最新的编码规范。

2.2 自动化测试

自动化测试用于隔离软件的特定部分或功能，并确保它们的行为正确。所有现有的测试必须通过，然后才能合并新代码。

2.3 所有新的 API 类和方法的附加测试

添加到 API 的任何新方法或类都必须附带有效的单元测试以验证其正确行为。这有助于保证不仅当前代码有效，而且未来的更改不会导致主分支不稳定。在适当的情况下，应创建系统测试以验证预期行为。

2.4 所有代码库更改和添加的文档

添加到代码库的所有类和方法都必须在源代码中包含详细的 docblocks，并在 README.md 文件中包含说明性文本。其他要求，例如最终用户文档的要求，可以在 CONTRIBUTING.md 文件中找到。

2.5 特定 Joomla 产品的其他要求

对 Joomla 产品（例如 CMS）的贡献可能会有比上面列出的要求更高的要求。例如，这些可能包括帮助屏幕、语言键和可测试的升级路径。请参阅相应的 CONTRIBUTING.md 以了解任何其他要求的完整详细信息。

3. 发布策略

发布策略描述了每个版本如何融入整体发布生命周期，并定义了它在该生命周期中必须达到的里程碑。

3.1 软件发布生命周期

软件发布生命周期由不同的阶段和里程碑组成，这些阶段和里程碑表达了软件在从计划到开发到发布和支持的过程中不断成熟的过程。并非每个版本都会经历每个可能的阶段。例如，修订版本通常会省略 alpha、beta 和候选版本里程碑。

3.1.1 计划阶段

规划阶段主要包括讨论，几乎没有或根本没有实际可用的软件。一个新功能的想法可能会在开发者邮件列表上发布“请求意见”（RFC）文档时，迈出实现的第一步。RFC是对一个想法及其潜在实现的讨论，并邀请更广泛的社区参与进一步的讨论、反馈和想法的完善。

在规划阶段，可能会生成一些代码片段或概念验证实现，以演示可行性或引发对该想法的进一步反馈和评估。

在此阶段发布的版本有时被称为“预发布版”。

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.0 发布 2 个月后，发布了 4.1。4.0 将不再受支持，4.1 将成为受支持的版本。
即使 4.1 是在 2 年活跃开发期内发布的唯一次要版本，生命周期结束日期也不会更改。

版本 4.8 在 4.0 的初始主要版本发布 2 年 10 个月后发布。

版本 4.8 超过了最初 2 年的活跃开发周期 10 个月。
版本 4.8 将从其次要版本发布之日起提供 2 年的支持期限。
主要版本 4 从其初始发布到其估计的生命周期结束，现在总共拥有 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 和 Release Candidate 版本（在 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 语言键

更改或删除语言键被视为向后兼容性中断。添加新语言键不是。实质性地更改与语言键关联的含义是兼容性中断。为了更准确的描述或正确的英式英语语法而重新措辞不是。

6.1.7 渲染的标记

目前，渲染的标记不受我们的向后兼容性承诺约束。我们会尽量避免以可能导致站点呈现不同的方式更改标记，但我们无法保证不会破坏任何内容。我们将在未来努力定义可能对标记做出向后兼容性承诺的方式，但我们目前尚未就可行的标准达成满意的共识。

6.1.8 URL

任何会导致 404（或其他错误）的 URL 更改，而之前返回 200 的 URL 更改，都是向后兼容性的中断。但是，如果更改导致重定向到新的 URL（返回 200），则这是可以接受的。

一般来说，如果更改了 URL，只要新的 URL 以相同的方式传递完全相同的资源，则不被视为向后兼容性的中断。例如，更改 URL 查询部分中参数的顺序不被视为中断。

各个产品可能具有除了上述列出的内容之外的向后兼容性约束。这些将在相应的 README.md 中记录。

6.2 弃用

可以在新的次要版本或新主要版本的第一个版本中将元素标记为已弃用。必须在文档中添加有关如何修改当前正在使用已标记为已弃用的元素的代码的建议。

产品本身不再使用的先前已弃用的元素必须在新主要系列的第一个版本中删除，但不得在次要或修补程序版本中删除。

例如，在 10.1 版本中弃用的代码计划在 11.0.0 版本中删除。在 11.0.0 中弃用的代码不能在 12.0.0 版本发布之前删除。

已弃用的代码将在相应的 docblock 中添加 @deprecated 标记，并在发行说明中进行说明。

生产部门领导层可以选择推迟删除已弃用的元素，如果认为合适的话。

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 注入攻击、远程文件包含攻击以及其他导致网站数据泄露的攻击载体。
中等	XSS 攻击、写入 ACL 违规（在未授权的情况下编辑或创建内容）。
低	读取 ACL 违规（在未授权的情况下读取内容）。

7.4.2 严重性

级别	描述	发布修复
严重	执行起来非常容易。不依赖任何外部信息（真正的 0 天攻击）。	尽快
高	执行起来中等容易。可能依赖于容易获得的外部信息。	根据 oCERT 指南
中等	执行起来不容易。可能依赖于敏感信息。	根据 oCERT 指南
低	执行起来很困难。依赖于敏感信息或需要特殊情况才能执行。	根据 oCERT 指南

附录 A：示例生命周期

以下提供示例以帮助理解其工作原理

日期	发行说明
3.3.0	新的次要版本；包括新功能。
3.3.1 到 3.3.7	七个修补程序版本，大约每月修复一次 bug；没有新功能。
3.4.0	合并了新功能和一些 bug 修补程序；触发新的次要版本发布。
3.4.1 到 3.4.3	大约每两个月发布一次 bug 修复版本。
3.4.4	在 3.4.3 发布两天后发布了关键安全修复程序
3.5.0	新功能已准备就绪并合并；在 3.4.3 发布大约一个月后发布
3.5.1 到 3.5.2	bug 修复版本。
4.0.0-Alpha1	团队在开发新功能时破坏了与3.x的兼容性。触发了主版本递增；alpha 过程开始。
3.5.3 到 3.5.7	bug 修复版本
4.0.0-Beta1 到 4.0.0-Beta4	版本 4.0 的功能完整测试版本
3.5.8	继续修复 3.5 的 bug
4.0.0-RC 到 4.0.0-GA	候选版本通过最终测试并发布了 4.0-GA
3.5.9	bug 修复版本。
4.0.1 到 4.0.3	新主版本发布后不可避免的 bug 涌现。
4.1.0	4.x系列中的新功能；触发次要版本递增。
4.1.1 到 4.1.9	定期发布 bug 修复版本。
4.2.0	合并了新功能以及一些 bug 和低优先级安全修复。
3.6.0	为3.x发布了一些次要新功能
4.3 到 4.7	在一段时间内发布了许多新功能。
3.6.1	次要 bug 修复；生产部门领导层注意到对3.x系列的兴趣明显下降；宣布3.x的下一个次要版本将进入长期支持阶段
4.8.0	4.x的新功能
3.7.0	LTS 版本发布；没有新功能；仅提供安全和主要 bug 支持。
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 日 — 正式获得生产领导团队批准采用。