Up to date
This page is up to date for Godot 4.1.
If you still find outdated information, please open an issue.
Godot release policy¶
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 versioning¶
Godot loosely follows Semantic Versioning with a
major.minor.patch versioning system, albeit with an interpretation of each
term adapted to the complexity of a game engine:
The
majorversion is incremented when major compatibility breakages happen which imply significant porting work to move projects from one major version to another.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
minorversion 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.
Tip
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.
The
patchversion is incremented for maintenance releases which focus on fixing bugs and security issues, implementing new requirements for platform support, and backporting safe usability enhancements. Patch releases are backwards compatible.Patch versions may include minor new features which do not impact the existing API, and thus have no risk of impacting existing projects.
Tip
Updating to new patch versions is therefore considered safe and strongly recommended to all users of a given stable branch.
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).
Release support timeline¶
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.
In a given minor release series, only the latest patch release receives support. If you experience an issue using an older patch release, please upgrade to the latest patch release of that series and test again before reporting an issue on GitHub.
Version |
Release date |
Support level |
Godot 4.2 (master) |
November 2023 (estimate) |
|
Godot 4.1 |
July 2023 |
|
Godot 4.0 |
March 2023 |
|
Godot 3.6 (3.x, LTS) |
Q3 2023 (estimate) |
|
Godot 3.5 |
August 2022 |
|
Godot 3.4 |
November 2021 |
|
Godot 3.3 |
April 2021 |
|
Godot 3.2 |
January 2020 |
|
Godot 3.1 |
March 2019 |
|
Godot 3.0 |
January 2018 |
|
Godot 2.1 |
July 2016 |
|
Godot 2.0 |
February 2016 |
Development. Receives new features, usability and
performance improvements, as well as bug fixes, while under development.
Receives fixes for bugs and security issues, as well as
patches that enable platform support.
No longer supported, as fully superseded by the compatible 3.5
release (last update: 3.4.5).