release_policy.rst 9.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160
  1. .. _doc_release_policy:
  2. Godot release policy
  3. ====================
  4. Godot's release policy is in constant evolution. The description below
  5. provides a general idea of what to expect, but what will actually
  6. happen depends on the choices of core contributors and the needs of the
  7. community at a given time.
  8. Godot versioning
  9. ----------------
  10. Godot loosely follows `Semantic Versioning <https://semver.org/>`__ with a
  11. ``major.minor.patch`` versioning system, albeit with an interpretation of each
  12. term adapted to the complexity of a game engine:
  13. - The ``major`` version is incremented when major compatibility breakages happen
  14. which imply significant porting work to move projects from one major version
  15. to another.
  16. For example, porting Godot projects from Godot 3.x to Godot 4.x requires
  17. running the project through a conversion tool, and then performing a number
  18. of further adjustments manually for what the tool could not do automatically.
  19. - The ``minor`` version is incremented for feature releases that do not break
  20. compatibility in a major way. Minor compatibility breakage in very specific
  21. areas *may* happen in minor versions, but the vast majority of projects
  22. should not be affected or require significant porting work.
  23. This is because Godot, as a game engine, covers many areas like rendering,
  24. physics, and scripting. Fixing bugs or implementing new features in one area
  25. might sometimes require changing a feature's behavior or modifying a class's
  26. interface, even if the rest of the engine API remains backwards compatible.
  27. .. tip::
  28. Upgrading to a new minor version is recommended for all users,
  29. but some testing is necessary to ensure that your project still behaves as
  30. expected.
  31. - The ``patch`` version is incremented for maintenance releases which focus on
  32. fixing bugs and security issues, implementing new requirements for platform
  33. support, and backporting safe usability enhancements. Patch releases are
  34. backwards compatible.
  35. Patch versions may include minor new features which do not impact the
  36. existing API, and thus have no risk of impacting existing projects.
  37. .. tip::
  38. Updating to new patch versions is therefore considered safe and strongly
  39. recommended to all users of a given stable branch.
  40. We call ``major.minor`` combinations *stable branches*. Each stable branch
  41. starts with a ``major.minor`` release (without the ``0`` for ``patch``) and is
  42. further developed for maintenance releases in a Git branch of the same name
  43. (for example patch updates for the 4.0 stable branch are developed in the
  44. ``4.0`` Git branch).
  45. Release support timeline
  46. ------------------------
  47. Stable branches are supported *at least* until the next stable branch is
  48. released and has received its first patch update. In practice, we support
  49. stable branches on a *best effort* basis for as long as they have active users
  50. who need maintenance updates.
  51. Whenever a new major version is released, we make the previous stable branch a
  52. long-term supported release, and do our best to provide fixes for issues
  53. encountered by users of that branch who cannot port complex projects to the new
  54. major version. This was the case for the 2.1 branch, and is the case for the
  55. 3.6 branch.
  56. In a given minor release series, only the latest patch release receives support.
  57. If you experience an issue using an older patch release, please upgrade to the
  58. latest patch release of that series and test again before reporting an issue
  59. on GitHub.
  60. +-------------+----------------------+--------------------------------------------------------------------------+
  61. | **Version** | **Release date** | **Support level** |
  62. +-------------+----------------------+--------------------------------------------------------------------------+
  63. | Godot 4.1 | Q2-Q3 2023 (estimate)| |unstable| *Development.* Receives new features as well as bug fixes |
  64. | (`master`) | | while under development. |
  65. +-------------+----------------------+--------------------------------------------------------------------------+
  66. | Godot 4.0 | March 2023 | |supported| Receives fixes for bugs, security and platform support |
  67. | | | issues, as well as backwards-compatible usability enhancements. |
  68. +-------------+----------------------+--------------------------------------------------------------------------+
  69. | Godot 3.6 | Q2-Q3 2023 (estimate)| |supported| *Beta.* Receives new features as well as bug fixes while |
  70. | (`3.x`, LTS)| | under development. Will be released *after* 4.0. |
  71. +-------------+----------------------+--------------------------------------------------------------------------+
  72. | Godot 3.5 | August 2022 | |supported| Receives fixes for bugs, security and platform support |
  73. | | | issues, as well as backwards-compatible usability enhancements. |
  74. +-------------+----------------------+--------------------------------------------------------------------------+
  75. | Godot 3.4 | November 2021 | |eol| No longer supported, as fully superseded by the compatible 3.5 |
  76. | | | release (last update: 3.4.5). |
  77. +-------------+----------------------+--------------------------------------------------------------------------+
  78. | Godot 3.3 | April 2021 | |eol| No longer supported, as fully superseded by the compatible 3.4 |
  79. | | | release (last update: 3.3.4). |
  80. +-------------+----------------------+--------------------------------------------------------------------------+
  81. | Godot 3.2 | January 2020 | |eol| No longer supported (last update: 3.2.3). |
  82. +-------------+----------------------+--------------------------------------------------------------------------+
  83. | Godot 3.1 | March 2019 | |eol| No longer supported (last update: 3.1.2). |
  84. +-------------+----------------------+--------------------------------------------------------------------------+
  85. | Godot 3.0 | January 2018 | |eol| No longer supported (last update: 3.0.6). |
  86. +-------------+----------------------+--------------------------------------------------------------------------+
  87. | Godot 2.1 | July 2016 | |eol| No longer supported (last update: 2.1.6). |
  88. +-------------+----------------------+--------------------------------------------------------------------------+
  89. | Godot 2.0 | February 2016 | |eol| No longer supported (last update: 2.0.4.1). |
  90. +-------------+----------------------+--------------------------------------------------------------------------+
  91. | Godot 1.1 | May 2015 | |eol| No longer supported. |
  92. +-------------+----------------------+--------------------------------------------------------------------------+
  93. | Godot 1.0 | December 2014 | |eol| No longer supported. |
  94. +-------------+----------------------+--------------------------------------------------------------------------+
  95. .. |supported| image:: img/supported.png
  96. .. |partial| image:: img/partial.png
  97. .. |eol| image:: img/eol.png
  98. .. |unstable| image:: img/unstable.png
  99. **Legend:**
  100. |supported| Full support –
  101. |partial| Partial support –
  102. |eol| No support (end of life) –
  103. |unstable| Development version
  104. Pre-release Godot versions aren't intended to be used in production and are
  105. provided for testing purposes only.
  106. .. seealso::
  107. See :ref:`doc_upgrading_to_godot_4` for instructions on migrating a project
  108. from Godot 3.x to 4.x.
  109. .. _doc_release_policy_when_is_next_release_out:
  110. When is the next release out?
  111. -----------------------------
  112. While Godot contributors aren't working under any deadlines, we strive to
  113. publish minor releases relatively frequently.
  114. In particular, after the very length release cycle for 4.0, we are pivoting to
  115. a faster paced development workflow, with the 4.1 release expected within late
  116. Q2 / early Q3 2023.
  117. Frequent minor releases will enable us to ship new features faster (possibly
  118. as experimental), get user feedback quickly, and iterate to improve those
  119. features and their usability. Likewise, the general user experience will be
  120. improved more steadily with a faster path to the end users.
  121. Maintenance (patch) releases are released as needed with potentially very
  122. short development cycles, to provide users of the current stable branch with
  123. the latest bug fixes for their production needs.
  124. The 3.6 release is still planned and should be the last stable branch of Godot
  125. 3.x. It will be a Long-Term Support (LTS) release, which we plan to support for
  126. as long as users still need it (due to missing features in Godot 4.x, or
  127. having published games which they need to keep updating for platform
  128. requirements).