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

Godot використовує систему версій ` Semantic Versioning <https://semver.org/>`__ major.minor.patch, але тлумачення кожного терміну адаптоване до складності ігрового движка:

  • Версія major змінюється коли відбуваються основні обриви сумісності, які передбачають значну переробку проєктів для переміщення їх з однієї великої версії до іншої.

    Наприклад, перенесення проектів Godot з Godot 3.x на Godot 4.x вимагає прогону проекту через інструмент конвертації, а потім виконання низки подальших налаштувань вручну для того, що інструмент не зміг зробити автоматично.

  • "Малу" версію збільшено для випусків функцій, які не порушують сумісність у значній мірі. Незначні порушення сумісності у дуже специфічних областях можуть траплятися у мінорних версіях, але на переважну більшість проектів це не повинно впливати або вимагати значних робіт з перенесення.

    Це пов'язано з тим, що Godot, як ігровий рушій, охоплює багато областей, таких як рендеринг, фізика та сценарії. Виправлення помилок або реалізація нових можливостей в одній області може іноді вимагати зміни поведінки функції або модифікації інтерфейсу класу, навіть якщо решта API рушія залишається сумісною зі зворотним зв'язком.

Порада

Оновлення до нової мінорної версії рекомендується всім користувачам, але необхідно провести певне тестування, щоб переконатися, що ваш проект працює належним чином.

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

    Ці версії можуть містити незначні нові функції, які не впливають на існуючий API, отже, нема ризику впливу на існуючі проєкти.

Порада

Тому оновлення до новіших патчів вважається безпечним і настійно рекомендується всім користувачам даної стабільної гілки.

Ми називаємо комбінації major.minor стабільними гілками. Кожна стабільна гілка починається з випуску major.minor (без 0 для patch) і далі розвивається для випусків технічного обслуговування у однойменній гілці Git'а (наприклад, оновлення для стабільної гілки 4.0 розробляються у гілці 4.0 Git'а).

Терміни підтримки релізу

Стабільні гілки підтримуються щонайменше до випуску наступної стабільної гілки, яка отримає перше оновлення у вигляді патчу. На практиці, ми підтримуємо стабільні гілки на основі найбільших зусиль до тих пір, поки у них є активні користувачі, які потребують оновлень.

Щоразу, коли виходить нова велика версія, ми робимо попередню стабільну гілку довгостроково підтримуваною і робимо все можливе, щоб виправити проблеми, з якими стикаються користувачі цієї гілки, які не можуть перенести складні проекти на нову велику версію. Так було у випадку з гілкою 2.1, так є і у випадку з гілкою 3.6.

У певній серії незначних випусків підтримується лише останній випуск виправлення. Якщо у вас виникла проблема з використанням старішого випуску виправлення, оновіть його до останнього випуску виправлення цієї серії та перевірте його ще раз, перш ніж повідомляти про проблему на GitHub.

Версія

** Дата виходу **

** Рівень підтримки **

Godot 4.2 (master)

Листопад 2023 року (орієнтовно)

|Нестабільний | Розробка. Отримує нові функції, покращення зручності використання та продуктивності, а також виправлення помилок, перебуваючи на стадії розробки.

Godot 4.1

Липень 2023 року

|Підтримується| Отримує виправлення помилок і проблем безпеки, а також патчі, які забезпечують підтримку платформи.

Godot 4.0

Березень 2023 року

|Підтримується| Отримує виправлення помилок і проблем безпеки, а також патчі, які забезпечують підтримку платформи.

Годо 3.6 (3.x, LTS)

3 квартал 2023 року (оцінка)

|Підтримується| Beta. Отримує нові функції, покращення зручності використання та продуктивності, а також виправлення помилок, поки перебуває на стадії розробки.

Godot 3.5

Серпень 2022

|Підтримується| Отримує виправлення помилок і проблем безпеки, а також патчі, які забезпечують підтримку платформи.

Godot 3.4

Листопад 2021

не підтримується Більше не підтримується, оскільки повністю замінений сумісним випуском 3.5 (останнє оновлення: 3.4.5).

Godot 3.3

Квітень 2021

не підтримується Більше не підтримується, оскільки повністю замінено сумісним випуском 3.4 (останнє оновлення: 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 не призначені для використання у виробництві і надаються для тестування.

Дивись також

See Upgrading from Godot 3 to Godot 4 for instructions on migrating a project from Godot 3.x to 4.x.

Яку версію використовувати для нового проекту?

We recommend using Godot 4.x for new projects, as the Godot 4.x series will be supported long after 3.x stops receiving updates in the future. One caveat is that a lot of third-party documentation hasn't been updated for Godot 4.x yet. If you have to follow a tutorial designed for Godot 3.x, we recommend keeping Upgrading from Godot 3 to Godot 4 open in a separate tab to check which methods have been renamed (if you get a script error while trying to use a specific node or method that was renamed in Godot 4.x).

If your project requires a feature that is missing in 4.x (such as GLES2/WebGL 1.0), you should use Godot 3.x for a new project instead.

Should I upgrade my project to use new engine versions?

Примітка

Upgrading software while working on a project is inherently risky, so consider whether it's a good idea for your project before attempting an upgrade. Also, make backups of your project or use version control to prevent losing data in case the upgrade goes wrong.

That said, we do our best to keep minor and especially patch releases compatible with existing projects.

The general recommendation is to upgrade your project to follow new patch releases, such as upgrading from 4.0.2 to 4.0.3. This ensures you get bug fixes, security updates and platform support updates (which is especially important for mobile platforms). You also get continued support, as only the last patch release receives support on official community platforms.

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+.

Коли наступний реліз?

Хоча дописувачі Godot не працюють в умовах дедлайнів, ми намагаємося публікувати невеликі релізи відносно часто.

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:

  • Істотні нововведення.

  • 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.