Attention: Here be dragons
This is the latest
(unstable) version of this documentation, which may document features
not available in or compatible with released stable versions of Godot.
Checking the stable version of the documentation...
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.6 分支也如此。
次版本号相同的一系列版本中，只有最新的补丁版本会得到支持。如果你在使用较旧的补丁版本时遇到问题，请在前往 GitHub 提交问题之前先升级到该系列的最新补丁版本并测试。
版本 |
发布日期 |
支持级别 |
Godot 4.3（master） |
2024 年六月（预计） |
|
Godot 4.2 |
2023 年 11 月 |
|
Godot 4.1 |
2023 年 7 月 |
|
Godot 4.0 |
2023 年 3 月 |
|
Godot 3.6（3.x、LTS） |
2024 年第一季度（预计） |
|
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 版本中缺失的功能（如GLE2/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.0 的 4 个月后发布了 4.1 版本，4.1 的 4 个月后发布了 4.2 版本
频繁发布的次要版本可以让我们能够更快地发布新功能（有可能是实验性的），快速获得用户反馈，并迭代以改进这些功能及其可用性。 同样地，更快到达最终用户，一般用户的体验就能够得到更稳定的改善。
维护（补丁）版本是按需发布的，开发周期可能很短，作用是为当前稳定分支的用户提供最新的错误修复，以满足他们的生产需求。
3.6 版本仍在计划中，它应该是 Godot 3.x 的最后一个稳定分支。 这将是一个长期支持 (LTS) 版本，只要用户仍然需要它，我们就计划对其提供支持（由于 Godot 4.x 中缺少功能，或者已发行的游戏需要持续更新以满足平台需求）。
引擎版本之间的兼容标准是怎样的？¶
备注
本节旨在供贡献者使用以确定哪些更改对于给定版本是安全的。 该列表并不详尽； 它只是概述了 Godot 开发过程中遇到的最常见的情况。
补丁版本中可以接收以下更改：
修复一个不会对大多数项目产生重大负面影响的 bug，比如视觉或物理 bug。Godot 的物理引擎不是确定性的，所以修复物理 bug 不会被认为会破坏兼容性。如果修复一个 bug 会产生可能影响很多项目的负面影响，应该将其设置为可选项（例如使用项目设置或单独的方法）。
为一个方法新增一个可选参数。
小规模的编辑器可用性调整。
需要注意的是，我们在每个后续的补丁发布中通常更加保守地处理允许的修复。 例如，4.0.1 可能会比 4.0.4 收到更具影响的修复。
以下更改在次要版本中是可接受的，但在补丁版本中则是不可接受的：
重大新特性。
重命名方法参数。在 C# 中，方法参数可以通过名称传递（但在 GDScript 中不行）。因此这可能会破坏一些使用 C# 的项目。
弃用方法、成员变量或类。 这是通过向其类引用添加一个已弃用标志来完成的，该标志将显示在编辑器中。 当一个方法被标记为已弃用时，它将在下一个*主要（major）*版本中删除。
影响默认项目主题视觉效果的更改。
某些引起了行为或输出的明显改变的错误修复，旨在更好地满足用户的期望。相比之下，在补丁版本中，我们可能倾向于保留一些错误行为，这样我们就不会破坏可能已经依赖该错误或使用了解决方法的现有项目。
导致了视觉变化的性能优化。
以下更改被视为**破坏兼容性**，并且只能在新的主要（major）版本中执行：
重命名或删除方法、成员变量或类。
通过让节点继承不同的类来修改节点的继承树。
改变项目设置的默认值会影响已存在的项目。如果想只影响到新项目，项目管理者应当用编写一份修改的
project.godot来代替。
由于 Godot 5.0 分支目前还没有建立，我们不建议这种破坏兼容性的更改。
备注
在以任何方式修改方法签名（包括添加可选参数）时，必须创建一个 GDExtension 兼容性方法。这确保了现有的 GDExtensions 在补丁和小版本更新中继续工作，从而使用户不必重新编译它们。有关更多信息，请参见 Handling compatibility breakages。