Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

Политика релизов Godot

Godot's release policy is in constant evolution. The description below provides a general idea of what to expect, but what will actually happen depends on the choices of core contributors and the needs of the community at a given time.

Информация о версии

Godot вольно следует за Semantic Versioning с системой управления версиями основная.дополнительная.патч, хотя и с интерпретацией каждого термина, адаптированной к сложности игрового движка:

  • Основная версия увеличивается, когда происходят серьезные нарушения совместимости, которые подразумевают значительную работу по переносу для перемещения проектов из одной основной версии в другую.

    For example, porting Godot projects from Godot 3.x to Godot 4.x requires running the project through a conversion tool, and then performing a number of further adjustments manually for what the tool could not do automatically.

  • The minor version is incremented for feature releases that do not break compatibility in a major way. Minor compatibility breakage in very specific areas may happen in minor versions, but the vast majority of projects should not be affected or require significant porting work.

    This is because Godot, as a game engine, covers many areas like rendering, physics, and scripting. Fixing bugs or implementing new features in one area might sometimes require changing a feature's behavior or modifying a class's interface, even if the rest of the engine API remains backwards compatible.

Совет

Upgrading to a new minor version is recommended for all users, but some testing is necessary to ensure that your project still behaves as expected.

  • Версия исправление увеличивается для выпусков обслуживания, которые сосредоточены на исправлении ошибок и проблем безопасности, реализации новых требований для поддержки платформы и резервном копировании улучшений для безопасного использования. Релизы исправлений обратно совместимы.

    Версии исправлений могут включать незначительные новые функции, которые не влияют на существующий API и, следовательно, не имеют риска повлиять на существующие проекты.

Совет

Поэтому обновление до новых версий исправлений считается безопасным и настоятельно рекомендуется всем пользователям данной стабильной ветви.

We call major.minor combinations stable branches. Each stable branch starts with a major.minor release (without the 0 for patch) and is further developed for maintenance releases in a Git branch of the same name (for example patch updates for the 4.0 stable branch are developed in the 4.0 Git branch).

Сроки поддержки релиза

Stable branches are supported at least until the next stable branch is released and has received its first patch update. In practice, we support stable branches on a best effort basis for as long as they have active users who need maintenance updates.

Whenever a new major version is released, we make the previous stable branch a long-term supported release, and do our best to provide fixes for issues encountered by users of that branch who cannot port complex projects to the new major version. This was the case for the 2.1 branch, and is the case for the 3.6 branch.

В данной серии второстепенных выпусков поддержку получает только последний выпуск исправлений. Если у вас возникла проблема с использованием более раннего выпуска исправлений, обновите его до последнего выпуска исправлений этой серии и проверьте ещё раз, прежде чем сообщать о проблеме на GitHub.

Версия

Дата выпуска

Уровень поддержки

Godot 4.3 (master)

April 2024 (estimate)

не стабильно Разрабатывается. Получает новые функции, улучшения использования и производительности, а также исправления ошибок, пока находится в стадии разработки.

Godot 4.2

November 2023

поддерживается Получает исправления ошибок и проблем с безопасностью, а также патчи, обеспечивающие поддержку платформы.

Godot 4.1

Июль 2023

поддерживается Получает исправления ошибок и проблем с безопасностью, а также патчи, обеспечивающие поддержку платформы.

Godot 4.0

Март 2023

Конец поддержки No longer supported (last update: 4.0.4).

Godot 3.6 (3.x, LTS)

Q1 2024 (estimate)

поддерживается Бета. Получает новые функции, улучшения использования и производительности, а также исправления ошибок, пока находится в стадии разработки.

Godot 3.5

Август 2022

поддерживается Получает исправления ошибок и проблем с безопасностью, а также патчи, обеспечивающие поддержку платформы.

Godot 3.4

Ноябрь 2021

Конец поддержки No longer supported (last update: 3.4.5).

Godot 3.3

Апрель 2021

Конец поддержки No longer supported (last update: 3.3.4).

Godot 3.2

Январь 2020

Конец поддержки Больше не поддерживается (последнее обновление: 3.2.3).

Godot 3.1

Март 2019

Конец поддержки Больше не поддерживается (последнее обновление: 3.1.2).

Godot 3.0

Январь 2018

Конец поддержки Больше не поддерживается (последнее обновление: 3.0.6).

Godot 2.1

Июль 2016

Конец поддержки Больше не поддерживается (последнее обновление: 2.1.6).

Godot 2.0

Февраль 2016

Конец поддержки Больше не поддерживается (Последнее обновление: 2.0.4.1).

Godot 1.1

Май 2015

Конец поддержки Больше не поддерживается.

Godot 1.0

Декабрь 2014

Конец поддержки Больше не поддерживается.

Легенда: поддерживается Полная поддержка - частичный Частичная поддержка - Конец поддержки Не поддерживается (завершено) - не стабильно Разрабатываемая версия

Предварительные версии Godot не предназначены для использования в производстве и предоставляются с только для тестирования.

См.также

См. Переход с Godot 3 на Godot 4 для получения инструкций по переносу проекта с Godot 3.x на 4.x.

Какую версию мне следует использовать для нового проекта?

Мы рекомендуем использовать Godot 4.x для новых проектов, поскольку серия Godot 4.x будет поддерживаться еще долгое время после того, как 3.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. Это гарантирует, что вы получите исправления багов, обновления безопасности и обновления поддержки платформ (которые особенно важны для мобильных платформ). Вы также получите постоянную поддержку, так как только последняя версия патча поддерживается на официальных платформах сообщества.

For minor releases, you should determine whether it's a good idea to upgrade on a case-by-case basis. We've made a lot of effort in making the upgrade process as seamless as possible, but some breaking changes may be present in minor releases, along with a greater risk of regressions. Some fixes included in minor releases may also change a class' expected behavior as required to fix some bugs. This is especially the case in classes marked as experimental in the documentation.

Major releases bring a lot of new functionality, but they also remove previously existing functionality and may raise hardware requirements. They also require much more work to upgrade to compared to minor releases. As a result, we recommend sticking with the major release you've started your project with if you are happy with how your project currently works. For example, if your project was started with 3.5, we recommend upgrading to 3.5.2 and possibly 3.6 in the future, but not to 4.0+, unless your project really needs the new features that come with 4.0+.

Когда следующий релиз?

While Godot contributors aren't working under any deadlines, we strive to publish minor releases relatively frequently.

In particular, after the very length release cycle for 4.0, we are pivoting to a faster paced development workflow, with the 4.1 release expected within late Q2 / early Q3 2023.

Frequent minor releases will enable us to ship new features faster (possibly as experimental), get user feedback quickly, and iterate to improve those features and their usability. Likewise, the general user experience will be improved more steadily with a faster path to the end users.

Сопровождающие релизы (исправления) будут выпускаться по мере необходимости с потенциально очень короткими циклами разработки, чтобы предоставить пользователям текущей стабильной ветки самые последние исправления ошибок.

The 3.6 release is still planned and should be the last stable branch of Godot 3.x. It will be a Long-Term Support (LTS) release, which we plan to support for as long as users still need it (due to missing features in Godot 4.x, or having published games which they need to keep updating for platform requirements).

What are the criteria for compatibility across engine versions?

Примечание

This section is intended to be used by contributors to determine which changes are safe for a given release. The list is not exhaustive; it only outlines the most common situations encountered during Godot's development.

The following changes are acceptable in patch releases:

  • Fixing a bug in a way that has no major negative impact on most projects, such as a visual or physics bug. Godot's physics engine is not deterministic, so physics bug fixes are not considered to break compatibility. If fixing a bug has a negative impact that could impact a lot of projects, it should be made optional (e.g. using a project setting or separate method).

  • Adding a new optional parameter to a method.

  • Small-scale editor usability tweaks.

Note that we tend to be more conservative with the fixes we allow in each subsequent patch release. For instance, 4.0.1 may receive more impactful fixes than 4.0.4 would.

The following changes are acceptable in minor releases, but not patch releases:

  • Significant new features.

  • Renaming a method parameter. In C#, method parameters can be passed by name (but not in GDScript). As a result, this can break some projects that use C#.

  • Deprecating a method, member variable, or class. This is done by adding a deprecated flag to its class reference, which will show up in the editor. When a method is marked as deprecated, it's slated to be removed in the next major release.

  • Changes that affect the default project theme's visuals.

  • Bug fixes which significantly change the behavior or the output, with the aim to meet user expectations better. In comparison, in patch releases, we may favor keeping a buggy behavior so we don't break existing projects which likely already rely on the bug or use a workaround.

  • Performance optimizations that result in visual changes.

The following changes are considered compatibility-breaking and can only be performed in a new major release:

  • Renaming or removing a method, member variable, or class.

  • Modifying a node's inheritance tree by making it inherit from a different class.

  • Changing the default value of a project setting value in a way that affects existing projects. To only affect new projects, the project manager should write a modified project.godot instead.

Since Godot 5.0 hasn't been branched off yet, we currently discourage making compatibility-breaking changes of this kind.

Примечание

When modifying a method's signature in any fashion (including adding an optional parameter), a GDExtension compatibility method must be created. This ensures that existing GDExtensions continue to work across patch and minor releases, so that users don't have to recompile them. See pull request #76446 for more information.