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

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

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

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

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

Порада

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

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

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

Порада

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

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

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

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

Кожного разу, коли випускається нова основна версія, ми робимо попередню стабільну гілку версією з довгостроковою підтримкою та робимо все можливе, щоб виправити проблеми, з якими стикаються користувачі цієї гілки, які не можуть перенести складні проекти на нову основну версію. Це було у випадку з гілкою 2.1 і такою є ситуація з гілкою 3.x.

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

Версія	Дата виходу	Рівень підтримки
Godot 4.7 (master)	2/3 квартал 2026 року (орієнтовно)	Розробка. Отримує нові функції, покращення зручності використання та продуктивності, а також виправлення помилок, поки знаходиться в розробці.
Godot 4.6	Січень 2026 року	Отримує виправлення помилок і проблем із безпекою, а також виправлення, які забезпечують підтримку платформи.
Godot 4.5	Вересень 2025 року	Отримує виправлення лише для проблем безпеки та підтримки платформи.
Godot 4.4	Березень 2025 року	No longer supported (last update: 4.4.1).
Godot 4.3	Серпень 2024	Більше не підтримується (останнє оновлення: 4.3).
Godot 4.2	Листопад 2023	Більше не підтримується (останнє оновлення: 4.2.2).
Godot 4.1	Липень 2023 року	Більше не підтримується (останнє оновлення: 4.1.4).
Godot 4.0	Березень 2023 року	Більше не підтримується (останнє оновлення: 4.0.4).
Godot 3.7 (3.x)	Наразі немає очікуваного прибуття	Бета-версія. Отримує нові функції, покращення зручності використання та продуктивності, а також виправлення помилок, поки знаходиться в розробці.
Godot 3.6	Вересень 2024 р	Отримує виправлення помилок і проблем із безпекою, а також виправлення, які забезпечують підтримку платформи.
Godot 3.5	Серпень 2022	Більше не підтримується (останнє оновлення: 3.5.3).
Godot 3.4	Листопад 2021	Більше не підтримується (останнє оновлення: 3.4.5).
Godot 3.3	Квітень 2021	Більше не підтримується (останнє оновлення: 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. Це гарантує, що ви отримаєте виправлення помилок, оновлення безпеки та оновлення підтримки платформи (що особливо важливо для мобільних платформ). Ви також отримуєте постійну підтримку, оскільки лише останній патч отримує підтримку на офіційних платформах спільноти.

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

Основні (мajor) релізи приносять багато нового функціоналу, але вони також вилучає раніше існуючий функціонал і можуть підвищувати вимоги до обладнання. Вони також вимагають значно більше роботи з оновленням, ніж мінорні. В результаті ми рекомендую зупинятися на основному релізі, з якого ви почали свій проект, якщо ви задоволені тим, як зараз працює ваш проект. Наприклад, якщо ваш проект починався з 3.5, рекомендуємо оновитися до 3.5.2 і можливо 3.6 в майбутньому, але не до 4.0+, якщо тільки ваш проект дійсно не потребує нових функцій, які постачаються з 4.0+.

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

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

Зокрема, після дуже довгого циклу випуску версії 4.0, ми переходимо до швидшого робочого процесу розробки: версія 4.1 вийшла через 4 місяці після 4.0, а 4.2 — через 4 місяці після 4.1.

Часті незначні (мінорні) випуски дозволять нам швидше постачати нові функції (можливо, як експериментальні), швидко отримувати відгуки користувачів і, на основі відгуків, покращувати новий функціонал. Відповідно, загальний користувацький досвід буде враховуватися з випуском стабільніших патчів, які будуть частіше випускатися.

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

Наразі немає запланованої дати випуску наступної проміжної версії 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 продовжуватимуть працювати з виправленнями та проміжними випусками, тож користувачам не доведеться їх перекомпілювати. Перегляньте Усунення порушень сумісності для отримання додаткової інформації.