Godot 发布策略
Godot 的发布政策是在不断改进的。以下内容提供了大致的预期结果，但实际会发生什么取决于核心贡献者的选择，以及社区在特定时期的需求。
Godot 版本
Godot 松散地遵循了语义化版本，采用了 major.minor.patch 的版本系统，不过对每个术语的解释都根据游戏引擎的复杂性进行了调整：
major（主要）版本在发生重大兼容性破坏时会增加，这意味着项目需要大量的移植工作，才能从一个主要版本迁移另一个主要版本。例如，将 Godot 项目从 Godot 3.x 移植到 Godot 4.x 时，需要通过转换工具运行项目，然后对工具无法自动完成的工作进行进一步的手动调整。
minor（次要）版本在不严重破坏兼容性的功能发布时增加。在次要版本中，某些特定领域可能会出现轻微兼容性破坏，但绝大多数项目不会受到影响，也不需要进行大量移植工作。这是因为 Godot 作为一款游戏引擎， 涵盖了渲染、物理和脚本等许多领域。修复某个领域的 Bug 或实现新功能，有时可能需要改变某个功能的行为，或者修改某个类的接口，即便是引擎 API 的其他部分仍然向后兼容。
小技巧
建议所有用户升级到新的次要版本，但有必要进行一些测试，以确保你的项目仍能按照预期的方式运行。
patch（补丁）版本是为维护版本而增加的，其重点是修复错误和安全问题，实现平台支持的新要求，以及反向移植安全可用性增强功能。补丁版本是向后兼容的。补丁版本可能包含一些不影响现有 API 的小的新功能，因此没有影响现有项目的风险。
小技巧
因此，更新到新的补丁版本被认为是安全的，并强烈推荐给特定稳定分支的所有用户。
我们将 major.minor 组合称为稳定分支。每个稳定分支都从 major.minor 版本开始（不写为 0 的 patch），后续维护版本的开发都位于同名的 Git 分支上（例如 4.0 稳定分支补丁更新的开发位于 4.0 Git 分支）。
发布支持时间表
对稳定分支的支持会至少持续到下一个稳定分支发布并获得第一个补丁更新。在实践中，只要稳定分支有需要维护更新的活跃用户，我们就会尽最大努力为其提供支持。
每当一个新的主要版本发布时，我们都会将之前的稳定分支作为长期支持的版本，并尽力为无法将复杂项目移植到新的主要版本的该分支用户，在遇到的问题时提供修复。2.1 分支就是如此，3.x 分支也是如此。
在给定的次要版本系列中，只有最新的补丁版本会获得支持。如果你在使用较旧的补丁版本时遇到问题，请先升级到该系列的最新补丁版本并再次测试，然后再在 GitHub 上报告问题。
版本 |
发布日期 |
支持级别 |
Godot 4.7（master） |
2026 年第二/三季度（预计） |
|
Godot 4.6 |
2026 年 1 月 |
|
Godot 4.5 |
2025 年 9 月 |
|
Godot 4.4 |
2025 年 3 月 |
|
Godot 4.3 |
2024 年 8 月 |
|
Godot 4.2 |
2023 年 11 月 |
|
Godot 4.1 |
2023 年 7 月 |
|
Godot 4.0 |
2023 年 3 月 |
|
Godot 3.7（3.x） |
目前没有预计时间 |
|
Godot 3.6 |
2024 年 9 月 |
|
Godot 3.5 |
2022 年 8 月 |
|
Godot 3.4 |
2021 年 11 月 |
|
Godot 3.3 |
2021 年 4 月 |
|
Godot 3.2 |
2020 年 1 月 |
|
Godot 3.1 |
2019 年 3 月 |
|
Godot 3.0 |
2018 年 1 月 |
|
Godot 2.1 |
2016 年 7 月 |
|
Godot 2.0 |
2016 年 2 月 |
|
Godot 1.1 |
2015 年 5 月 |
|
Godot 1.0 |
2014 年 12 月 |
|
图例：
完全支持 – 
部分支持 – 
不支持（生命结束）– 
开发版本
Godot 的预览版不是为生产使用准备的，仅供测试目的使用。
参见
有关将项目从 Godot 3.x 迁移到 4.x 的说明，请参阅《从 Godot 3 升级到 Godot 4》。
新项目应该使用哪个版本？
我们建议在新项目中使用 Godot 4.x，因为在未来 3.x 停止接收更新后很长时间内仍将支持 Godot 4.x 系列。 需要注意的是，许多第三方文档尚未针对 Godot 4.x 进行更新。 如果你必须学习为 Godot 3.x 设计的教程，我们建议在单独的选项卡中保持《从 Godot 3 升级到 Godot 4》打开，以检查哪些方法已被重命名（如果你在尝试使用 Godot 4.x 中已被重命名的特定节点或方法时出现脚本错误）。
如果你的项目需要 4.x 版本中缺失的功能（如 GLES2/WebGL 1.0），那么你应该为新项目使用 Godot 3.x。
我是否应该升级我的项目以使用新的引擎版本？
备注
在项目中途升级软件本身就有风险，所以在尝试升级之前请慎重考虑，你的项目是否能够从升级中获益。另外，请做好项目的备份或者使用版本控制系统，防止在升级出错时造成数据的丢失。
也就是说，我们尽力确保的是次要版本，尤其是补丁版本与现有项目兼容。
一般性建议是升级你的项目以跟进新的补丁版本，例如从 4.0.2 升级到 4.0.3。 这可以确保你获得错误修复、安全更新和平台支持更新（这对于移动平台来说尤其重要）。 你还可以获得持续的支持，因为只有最新的补丁版本才会在官方社区平台上获得支持。
对于次要版本，你应该根据具体情况具体分析的原则，来确定升级是否是个好主意。 我们已经付出了很大的努力来使升级过程尽可能无缝，但次要版本中可能会出现一些重大更改，并且回归的风险也更大。次要版本中包含的某些修复，也可能会根据修复某些错误的需要而更改类的预期行为。 在文档中标记为实验性的类中尤其如此。
主要版本带来了许多新功能，但它们也会移除以前有的功能，并有可能提高硬件要求。与次要版本相比，它们还需要更多的工作来升级。 因此，如果你对项目当前的运行方式感到满意，我们建议你坚持使用你开始项目时使用的主要版本。 例如，如果你的项目是从 3.5 开始的，那么我们建议升级到 3.5.2，将来也许升级到 3.6，但不要升级到 4.0+，除非你的项目确实需要 4.0+ 带来的新功能。
下一个版本什么时候发布？
虽然 Godot 贡献者的工作没有设置截止日期，但我们会努力相对频繁地发布次要版本。
尤其是在 4.0 经历了漫长的发布周期之后，我们正在转向更快节奏的开发工作流程，4.1 在 4.0 发布 4 个月后发布，4.2 在 4.1 发布 4 个月后发布。
频繁发布次要版本可以让我们能够更快地发布新功能（有可能是实验性的），快速获得用户反馈，并迭代以改进这些功能及其可用性。同样，通过更快的路径到达最终用户，总体的用户体验将得到更稳定的改善。
维护（补丁）版本是按需发布的，开发周期可能很短，作用是为当前稳定分支的用户提供最新的错误修复，以满足他们的生产需求。
目前没有计划发布下一个 3.x 小版本 3.7 的日期。当前的稳定版本 3.6 可能是 Godot 3.x 的最后一个稳定分支。Godot 3.x 将根据贡献者的努力继续提供支持，只要维护者仍在维护它。
引擎版本之间的兼容标准是怎样的？
备注
本节旨在供贡献者使用以确定哪些更改对于给定版本是安全的。 该列表并不详尽； 它只是概述了 Godot 开发过程中遇到的最常见的情况。
补丁版本中可以接收以下更改：
以不会对大多数项目产生重大负面影响的方式修复一个错误，例如一个视觉或物理错误。Godot 的物理引擎不是确定性的，因此物理错误修复不被认为会破坏兼容性。如果修复一个错误会产生可能会影响很多项目的负面影响，则应将其设置为可选项（例如使用项目设置或单独的方法）。
向方法添加新的可选参数。
小规模的编辑器可用性调整。
需要注意的是，我们在每个后续的补丁发布中通常更加保守地处理允许的修复。 例如，4.0.1 可能会比 4.0.4 收到更具影响的修复。
以下更改在次要版本中是可接受的，但在补丁版本中则是不可接受的：
重大新特性。
重命名方法参数。在 C# 中，方法参数可以通过名称传递（但在 GDScript 中不行）。因此这可能会破坏一些使用 C# 的项目。
弃用方法、成员变量或类。 这是通过向其类参考中添加一个已弃用标志来完成的，该标志将显示在编辑器中。 当一个方法被标记为已弃用时，它将在下一个主要版本中移除。
影响默认项目主题视觉效果的更改。
某些引起了行为或输出的明显改变的错误修复，旨在更好地满足用户的期望。相比之下，在补丁版本中，我们可能倾向于保留一些错误行为，这样我们就不会破坏可能已经依赖该错误或使用了变通方法的现有项目。
导致了视觉变化的性能优化。
以下更改被视为破坏兼容性，并且只能在新的主要版本中执行：
重命名或删除方法、成员变量或类。
通过让节点继承不同的类来修改节点的继承树。
更改项目设置值的默认值，从而影响现有项目。如果只想影响新项目，项目管理器应改为编写修改后的
project.godot。
由于 Godot 5.0 分支目前还没有建立，我们目前不鼓励进行此类破坏兼容性的更改。
备注
在以任何方式修改方法签名（包括添加可选参数）时，必须创建一个 GDExtension 兼容性方法。这确保了现有的 GDExtensions 能够在补丁和次要版本更新中继续工作，从而使用户不必重新编译它们。有关更多信息，请参见《处理兼容问题》。