Godot 发布策略

Godot 的发布政策是在不断改进的。以下内容是为了给各位提供一个大致的预期，但实际会发生什么取决于核心贡献者的选择，以及社区在特定时期的需求。

Godot 版本

Godot 松散地遵循了语义版本学，采用了 major.minor.patch 的版本系统，不过对每个术语的解释都根据游戏引擎的复杂性进行了调整：

• major（主要）版本在发生重大不兼容时会增加，这意味着项目需要大量的移植工作才能从一个主要版本迁移另一个主要版本。

  例如，将 Godot 项目从 Godot 2.1 移植到 Godot 3.0 时，需要通过转换工具运行项目，然后对工具无法自动完成的工作进行进一步的手动调整。

• minor（次要）版本在不严重破坏兼容性的功能发布时增加。在非常特定的领域中，小版本可能会出现轻微的兼容性问题，但绝大部分项目并不会受到影响或需要做大量的移植工作。

  原因在于，作为游戏引擎，Godot 涵盖了渲染、物理、脚本等多个领域，修复某个领域的 Bug 或实现新功能，有时可能需要改变某个功能的行为，或者修改某个类的接口，即便是引擎 API 的其他部分仍然向后兼容。

小技巧

因此，建议所有用户升级到新的次要版本，但有必要进行一些测试，以确保你的项目在新的次要版本中仍能按照预期的方式运行。

• patch（补丁）版本是为维护版本而增加的，其重点是修复错误和安全问题，实现平台支持的新要求，以及可用性安全性增强。补丁版本是向后兼容的。

  补丁版本可能包含一些不影响现有 API 的小的新功能，因此没有影响现有项目的风险。

小技巧

因此，更新到新的补丁版本被认为是安全的，并强烈推荐给特定稳定分支的所有用户。

我们将 major.minor 组合称为稳定分支。每个稳定分支都从 major.minor 版本开始（不写为 0 的 patch），后续维护版本的开发都位于同名的 Git 分支上（例如 3.3 稳定分支补丁更新的开发位于 3.3 Git 分支）。

注解

如导言中所述，Godot 的发布规则在不断改进，早期的 Godot 版本可能没有严格遵守上述规则。尤其是 3.2 稳定分支在 3.2.2 中获得了一些新的功能，这些新功能其实应该进行 minor 版本的递增。

发布支持时间表

对稳定分支的支持会至少持续到下一个稳定分支发布并获得第一个补丁更新。在实践中，只要还有活跃用户需要维护更新，我们就会以最大努力去支持稳定分支。

每当一个新的主版本发布时，我们都会对上一个稳定分支提供长期的支持，并尽最大努力为那些无法将复杂项目移植到新的主要版本中的旧版用户提供修复帮助。2.1 分支如此，到 Godot 4.0 发布时，最新的 3.x 稳定分支也会如此。

次版本号相同的一系列版本中，只有最新的补丁版本会得到支持。如果你在使用较旧的补丁版本时遇到问题，请在前往 GitHub 提交问题之前先升级到该系列的最新补丁版本并测试。

图例： 完全支持 - 部分支持 - 不支持（生命结束） - 开发版本

Godot 的预览版不是为生产使用准备的，仅用于测试目的。

下一个版本什么时候发布？

虽然 Godot 贡献者的工作没有设置截止日期，但通常每年都会发布一个主要或次要版本，每一个版本之间都有数次维护更新。

自 Godot 3.3 以来，我们的目标是加快次要版本的开发周期，所以可以预期每 3 到 6 个月更新一个次要版本。

维护（补丁）版本将根据需要发布，开发周期可能很短，作用是为当前稳定分支的用户提供最新的错误修复，以满足他们的生产需求。

至于即将到来的 Godot 4.0，我们只能说，我们的目标是在 2022 年 发布，再近的预期就很难保证了。一旦 Godot 4.0 的主要功能最终确定下来，我们就会尽快发布 Alpha 版本。