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 버전 관리

Godot는 메이저(major).마이너(minor).패치(patch) 버전 시스템을 사용하여 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)

불안정 Development. Receives new features, usability and performance improvements, as well as bug fixes, while under development.

Godot 4.2

November 2023

지원됨 Receives fixes for bugs and security issues, as well as patches that enable platform support.

Godot 4.1

July 2023

지원됨 Receives fixes for bugs and security issues, as well as patches that enable platform support.

Godot 4.0

March 2023

지원 종료 No longer supported (last update: 4.0.4).

Godot 3.6 (3.x, LTS)

Q1 2024 (estimate)

지원됨 Beta. Receives new features, usability and performance improvements, as well as bug fixes, while under development.

Godot 3.5

2022년 8월

지원됨 Receives fixes for bugs and security issues, as well as patches that enable platform support.

Godot 3.4

2021년 11월

지원 종료 No longer supported (last update: 3.4.5).

Godot 3.3

2021년 4월

지원 종료 No longer supported (last update: 3.3.4).

Godot 3.2

2020년 1월

지원 종료 지원 종료(마지막 업데이트 : 3.2.3).

Godot 3.1

2019년 3월

지원 종료 지원 종료(마지막 업데이트 : 3.1.2).

Godot 3.0

2018년 1월

지원 종료 지원 종료(마지막 업데이트 : 3.0.6).

Godot 2.1

2016년 7월

지원 종료 지원 종료(마지막 업데이트 : 2.1.6).

Godot 2.0

2016년 2월

지원 종료 지원 종료(마지막 업데이트 : 2.0.4.1).

Godot 1.1

2015년 5월

지원 종료 지원 종료.

Godot 1.0

2014년 12월

지원 종료 지원 종료.

범례: 지원됨 지원 - 부분적 부분 지원 - 지원 종료 지원 없음(종료) - 불안정 개발 버전

Godot의 사전 배포판은 제작에 사용되는 것을 염두한 것이 아니며 테스팅 목적으로만 제공됩니다.

더 보기

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

Which version should I use for a new project?

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

다음 버전은 언제 출시되나요?

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.