release_policy.rst 8.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150
  1. .. _doc_release_policy:
  2. Godot release policy
  3. ====================
  4. Godot's release policy is in constant evolution. What is described below is
  5. intended to give 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 2.1 to Godot 3.0 required
  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 which 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. The reason for this is that as a game engine, Godot covers many areas such
  24. as rendering, physics, scripting, etc., and fixing bugs or implementing new
  25. features in a given area may sometimes require changing the behavior of a
  26. feature, or modifying the interface of a given class, even if the rest of
  27. the engine API remains backwards compatible.
  28. .. tip::
  29. Upgrading to a new minor version is therefore recommended for all users,
  30. but some testing is necessary to ensure that your project still behaves as
  31. expected in a new minor version.
  32. - The ``patch`` version is incremented for maintenance releases which focus on
  33. fixing bugs and security issues, implementing new requirements for platform
  34. support, and backporting safe usability enhancements. Patch releases are
  35. backwards compatible.
  36. Patch versions may include minor new features which do not impact the
  37. existing API, and thus have no risk of impacting existing projects.
  38. .. tip::
  39. Updating to new patch versions is therefore considered safe and strongly
  40. recommended to all users of a given stable branch.
  41. We call ``major.minor`` combinations *stable branches*. Each stable branch
  42. starts with a ``major.minor`` release (without the ``0`` for ``patch``) and is
  43. further developed for maintenance releases in a Git branch of the same name
  44. (for example patch updates for the 3.3 stable branch are developed in the
  45. ``3.3`` Git branch).
  46. .. note::
  47. As mentioned in the introduction, Godot's release policy is evolving, and
  48. earlier Godot releases may not have followed the above rules to the letter.
  49. In particular, the 3.2 stable branch received a number of new features in
  50. 3.2.2 which would have warranted a ``minor`` version increment.
  51. Release support timeline
  52. ------------------------
  53. Stable branches are supported *at minimum* until the next stable branch is
  54. released and has received its first patch update. In practice, we support
  55. stable branches on a *best effort* basis for as long as they have active users
  56. who need maintenance updates.
  57. Whenever a new major version is released, we make the previous stable branch a
  58. long-term supported release, and do our best to provide fixes for issues
  59. encountered by users of that branch who cannot port complex projects to the new
  60. major version. This was the case for the 2.1 branch, and will be the case for
  61. the latest 3.x stable branch by the time Godot 4.0 is released.
  62. In a given minor release series, only the latest patch release receives support.
  63. If you experience an issue using an older patch release, please upgrade to the
  64. latest patch release of that series and test again before reporting an issue
  65. on GitHub.
  66. +-------------+----------------------+--------------------------------------------------------------------------+
  67. | **Version** | **Release date** | **Support level** |
  68. +-------------+----------------------+--------------------------------------------------------------------------+
  69. | Godot 4.0 | Q4 2022 | |unstable| *Alpha.* Current focus of development (unstable). |
  70. +-------------+----------------------+--------------------------------------------------------------------------+
  71. | Godot 3.6 | Q4 2022 | |supported| *Beta.* Receives new features as well as bug fixes while |
  72. | | | under development. |
  73. +-------------+----------------------+--------------------------------------------------------------------------+
  74. | Godot 3.5 | August 2022 | |supported| Receives fixes for bugs, security and platform support |
  75. | | | issues, as well as backwards-compatible usability enhancements. |
  76. +-------------+----------------------+--------------------------------------------------------------------------+
  77. | Godot 3.4 | November 2021 | |partial| Receives fixes for security and platform support issues only. |
  78. +-------------+----------------------+--------------------------------------------------------------------------+
  79. | Godot 3.3 | April 2021 | |eol| No longer supported as fully superseded by the compatible 3.4 |
  80. | | | release (last update: 3.3.4). |
  81. +-------------+----------------------+--------------------------------------------------------------------------+
  82. | Godot 3.2 | January 2020 | |eol| No longer supported (last update: 3.2.3). |
  83. +-------------+----------------------+--------------------------------------------------------------------------+
  84. | Godot 3.1 | March 2019 | |eol| No longer supported (last update: 3.1.2). |
  85. +-------------+----------------------+--------------------------------------------------------------------------+
  86. | Godot 3.0 | January 2018 | |eol| No longer supported (last update: 3.0.6). |
  87. +-------------+----------------------+--------------------------------------------------------------------------+
  88. | Godot 2.1 | July 2016 | |eol| No longer supported (last update: 2.1.6). |
  89. +-------------+----------------------+--------------------------------------------------------------------------+
  90. | Godot 2.0 | February 2016 | |eol| No longer supported (last update: 2.0.4.1). |
  91. +-------------+----------------------+--------------------------------------------------------------------------+
  92. | Godot 1.1 | May 2015 | |eol| No longer supported. |
  93. +-------------+----------------------+--------------------------------------------------------------------------+
  94. | Godot 1.0 | December 2014 | |eol| No longer supported. |
  95. +-------------+----------------------+--------------------------------------------------------------------------+
  96. .. |supported| image:: img/supported.png
  97. .. |partial| image:: img/partial.png
  98. .. |eol| image:: img/eol.png
  99. .. |unstable| image:: img/unstable.png
  100. **Legend:**
  101. |supported| Full support –
  102. |partial| Partial support –
  103. |eol| No support (end of life) –
  104. |unstable| Development version
  105. Pre-release Godot versions aren't intended to be used in production and are
  106. provided for testing purposes only.
  107. .. _doc_release_policy_when_is_next_release_out:
  108. When is the next release out?
  109. -----------------------------
  110. While Godot contributors aren't working under any deadlines, we strive to
  111. publish minor releases relatively frequently, with an average of two 3.x minor
  112. releases per year since Godot 3.3.
  113. Maintenance (patch) releases are released as needed with potentially very
  114. short development cycles, to provide users of the current stable branch with
  115. the latest bug fixes for their production needs.
  116. As for the upcoming Godot 4.0, as of August 2022, we are aiming for a *beta*
  117. release in Q3 2022, and possibly a stable release by Q4 2022 (but experience
  118. has shown time and time again that such estimates tend to be overly optimistic).
  119. `Follow the Godot blog <https://godotengine.org/news>`__ for the latest updates.