Joomla的发布周期

随着Joomla最新版本的不断更新发布，你是否感觉到Joomla的发布周期和以前已经不一样，你是否想了解Joomla 6、Joomla 7、Joomla 8或未来的更高更新版本会在什么时候发布？野草工作室带大家了解一下Joomla的发布周期，从而对自己网站以后的更新和维护做到心里有数。

以下软件发布周期描述适用于我们的主要产品——内容管理系统 (CMS)。Joomla 从 4.0 版本开始采用基于时间的发布周期。这意味着每两年发布一个 CMS 的主要版本。发布日期计划在奇数年的 10 月份（例如 2025、2027、2029 年……）。在这两年中，我们每 6 个月发布一个次要版本。补丁版本通常每 6 周发布一次。

生命周期的各个阶段

软件发布生命周期由不同的阶段和里程碑组成，这些阶段和里程碑体现了软件从规划、开发到发布和支持过程中的成熟度。并非每次发布都会经历所有阶段。例如，补丁版本通常会省略 alpha 和 beta 阶段。

规划阶段

规划阶段主要以讨论为主，实际软件可能很少或根本没有。一项新功能的构想可能会通过在GitHub上发起 RFC 讨论或发布RFC 文档来迈出实现的第一步。RFC旨在探讨某个想法及其潜在实现方式，并邀请更广泛的社区参与进一步的讨论、反馈和完善。

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

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

开发和测试阶段

在此阶段，软件将按照计划进行积极的编写、测试和文档编制。这项工作由CMS维护团队和软件系列发布经理协调完成。特别是对于较大的功能，生产部门将进行投票，以决定该功能是否包含在下一个版本中。强烈建议尽早提出想法并获得批准。

在此阶段，将发布标记为“alpha”、“beta”和“候选版本”的版本。

释放阶段

当第一个“正式发布版”发布时，软件便进入发布阶段。在此阶段，代码被认为已达到生产质量标准，适合普通用户使用。

在此阶段发布的版本将遵循版本编号方案，该方案强制执行语义版本控制，如本文档的版本编号部分所述。

支持阶段

在发布 x.0.0 版本后，我们将进入该系列的支持阶段。在此阶段，我们将修复漏洞并发布补丁版本。补丁版本仅用于修复漏洞，新功能可以添加到次要版本中，但前提是不能破坏向后兼容性。

我们计划发布 4 个小版本。最后一个小版本是过渡版本，不包含任何新功能，旨在为下一个主要版本做准备。升级到下一个主要版本只能从过渡版本（通常是 xy4 版本）进行。在 x.4.0 发布之后，我们将进行为期一年的漏洞修复和为期两年的安全更新。

当下一个小版本发布时，旧版本软件将不再获得支持。例如，x.2.z 版本在 x.3.0 版本发布后即停止支持。

软件里程碑

软件发布周期分为四个里程碑：alpha 版、beta 版、候选发布版和正式发布版。

阿尔法

Alpha 版本标志着软件中包含一些可以进行测试的新技术，但软件的功能尚未完全实现。Alpha 版本软件也可用于演示各种功能的组合，以检验它们是否能够协同工作。某些功能可能会在后续版本中被移除。

alpha 版本的目标受众是开发社区，包括可能受到核心变更或新功能影响的第三方开发人员。

Alpha 版软件不适用于生产环境。

Beta

Beta 版本已基本完成所有功能，但仍不适用于生产环境。该软件需要进行全面的回归测试、安全性测试和稳定性测试。

第三方扩展程序开发者应该针对所有测试版版本测试他们的产品，并将任何问题报告到问题跟踪器中。等待正式版发布为时已晚。

发布候选版本 (RC)

发布候选版本的目的是测试最终的打包和发布流程，以确保软件在首次正式发布前一切就绪，可以进入发布阶段。

在发布候选版本之前，必须添加所有语言标签（语言冻结）。

第三方扩展开发者务必对所有候选版本进行最终测试，并立即报告任何错误。但是，候选版本只会修复涉及核心软件或所包含扩展的重大“致命”错误。仅影响第三方软件的问题在此阶段不会修复。不会添加或移除任何功能。

候选版本被认为是完整且适用于生产环境的，但只有了解相关风险的专业人员才能将其部署到生产环境中。除非出现重大问题，否则候选版本有可能被重新标记为正式发布版本。

正式发布 (GA)

正式发布里程碑表明该版本非常稳定，适合最终用户使用。只有在所有“发布阻碍”问题都已修复后，才能发布此版本。

版本编号

软件版本发布是指分发软件代码、文档和支持材料。每个版本都有一个版本标识符，其结构旨在帮助读者了解该版本与其他版本之间的关系。

Joomla 遵循语义化版本控制（2.0.0），本文档也使用了其中定义的术语。

总而言之，Joomla 的版本标识符遵循三级数字约定，其中级别由变更重要性定义。

主要.次要.补丁

在哪里

1. 主版本号递增表示向后兼容性中断。
2. 次版本标识符的增加表示新增功能或现有功能发生了重大变化。
3. 补丁版本标识符的递增表示错误已被修复。

请参阅SemVer文档了解完整详情。有关我们产品向后兼容性的更多信息，请参阅“向后兼容性”部分。

升级

从产品的一个版本升级到任何后续版本的目标始终是尽可能简化和便捷。然而，由于实际上无法支持从一个任意版本直接升级到任何其他任意版本，因此我们制定了将支持的最小升级路径。

拥有此受支持的升级路径至关重要，因为在任何新版本开发过程中都必须对此路径进行测试，并且这将是代码验收的必要条件。第三方扩展开发者也应了解此受支持的升级路径，以便确保他们的产品也能沿同一路径进行升级/迁移。

升级应该只需点击一下即可完成。但也有可能，升级到下一个主要版本时，用户需要按照一系列手动步骤才能成功更新网站。

总而言之，支持的升级路径始终是先升级到当前正在使用的主要系列中已完全修补的次要版本，然后再更新到下一个连续主要系列中已完全修补的最新次要版本。

补丁发布

补丁版本必须能够通过自动化流程应用，并且成功率要非常高。

支持的升级路径到下一个连续的小版本或大版本，前提是当前已安装的小版本系列中的所有补丁都已应用。

小版本

次要版本更新应能通过“一键升级”流程轻松完成，且成功率较高。由于可能添加了新功能，次要版本更新也可能引入新的错误，这些错误将在后续的补丁版本中修复。次要版本更新可能会降低系统稳定性，而补丁版本更新则始终旨在提高系统稳定性。因此，次要版本更新通常应由人工操作，以便进行后续测试，确保升级成功。

重要发布

主要版本更新应该能够通过“一键升级”流程应用，并且成功率要高。

升级到下一个主版本号的前提是，当前安装的次版本号已更新至该主版本号系列的最新版本。次版本号完全更新后，即可将网站升级到下一个主版本号。

示例升级路径

例如，假设当前已完全打好补丁的受支持版本为 4.4.2、5.4.3 和 6.2.3。同时假设 4.4 次要版本的最新补丁是 4.4.2。我们有一个站点运行的是 4.2.9 版本，需要将其升级到最新的 6.2.3 版本。那么，受支持的升级路径包含以下一系列单独的升级步骤：

1. 应用 4.2.9 至 4.4.2 的补丁。
2. 从 4.4.2 更新到 5.4.3。
3. 从 5.4.3 更新到 6.2.3。

请注意，根据定义，已停止支持的版本更新将不再受支持。但是，最后一个受支持的更新路径很可能仍然有效。