From 4ec75adb7660b5b08de09c2896048f8d878d9a27 Mon Sep 17 00:00:00 2001 From: Max Hilbrunner Date: Tue, 18 Apr 2023 00:37:54 +0200 Subject: [PATCH] Review, update Release Policy for Godot 4 --- about/release_policy.rst | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/about/release_policy.rst b/about/release_policy.rst index dd9cb1a75..b279364d6 100644 --- a/about/release_policy.rst +++ b/about/release_policy.rst @@ -1,13 +1,11 @@ -:article_outdated: True - .. _doc_release_policy: Godot release policy ==================== -Godot's release policy is in constant evolution. What is described below is -intended to give a general idea of what to expect, but what will actually -happen depends on the choices of core contributors, and the needs of the +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 @@ -30,15 +28,14 @@ term adapted to the complexity of a game engine: areas *may* happen in minor versions, but the vast majority of projects should not be affected or require significant porting work. - The reason for this is that as a game engine, Godot covers many areas such - as rendering, physics, scripting, etc., and fixing bugs or implementing new - features in a given area may sometimes require changing the behavior of a - feature, or modifying the interface of a given class, even if the rest of - the engine API remains backwards compatible. + 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 therefore recommended for all users, + 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. @@ -64,7 +61,7 @@ further developed for maintenance releases in a Git branch of the same name Release support timeline ------------------------ -Stable branches are supported *at minimum* until the next stable branch is +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.