Godotリリースポリシー
Godotのリリースポリシーは常に進化しています。以下の説明は、期待される基本的な考えを示すためにありますが、実際にどうなるかは、コア貢献者たちによる選択と、その時点でのコミュニティのニーズに依存します。
Godotのバージョン管理
Godotは、セマンティック・バージョニング方式 をゆるやかに踏襲した、 major.minor.patch バージョニング方式を採用しています。ただし、各項目はゲームエンジンの複雑さに合わせて解釈しています:
majorバージョンは、大きな互換性の破壊が発生し、プロジェクトをあるメジャーバージョンから別のメジャーバージョンに移すために多くの移植作業が必要になるときに増やされます。例えば、GodotプロジェクトをGodot 3.xからGodot 4.xに移植するには、変換ツールを使ってプロジェクトを実行した後、ツールが自動的にできない部分を手動で調整する必要がありました。
minorバージョンは、大きな互換性の破壊を伴わない機能のリリースに対して増加されます。マイナーバージョンでは、非常に限られた部分でマイナーな互換性の破壊が起こる かも しれませんが、大多数のプロジェクトでは影響を受けず、大幅な移植作業も必要ありません。その理由として、ゲームエンジンであるGodotは、レンダリング、物理、スクリプトなど様々な分野をカバーしており、ある部分のバグ修正や新機能の実装には、他のエンジンAPIが後方互換性を保っていても、ある機能の動作を変更したり、あるクラスのインターフェースを変更したりする必要がある場合があるからです。
Tip
そのため、新しいマイナーバージョンへのアップグレードはすべてのユーザーに推奨されますが、プロジェクトが新しいマイナーバージョンでも期待通りに動作することを確認するためには、いくつかのテストが必要です。
patchバージョンは、メンテナンスリリースにおいて増加します。バグやセキュリティ問題の修正、プラットフォーム対応のための新しい要件の実装、安全な使い勝手向上のバックポートなどが中心になります。パッチリリースには後方互換性があります。パッチ版にはマイナーな新機能が含まれている場合がありますが、既存のAPIに影響を与えないため、既存のプロジェクトに影響を与えるリスクはありません。
Tip
したがって、新しいパッチバージョンへのアップデートは安全であるとみなされ、いずれの安定版ブランチにおける全ユーザーに強く推奨されます。
私たちは major.minor の組み合わせを 安定版(stable) ブランチ と呼んでいます。それぞれの安定版ブランチは、 major.minor のリリース ( patch の 0 を除いたもの) から始まり、同じ名前の Git ブランチでメンテナンスリリースのための開発が進められます (例えば、4.0 stableブランチのパッチアップデートは 4.0 の Git ブランチで開発されます)。
リリースサポートのタイムライン
安定版ブランチは、次の安定版ブランチがリリースされ、最初のパッチアップデートを受けるまで、 最低限 サポートされます。実際には、メンテナンスアップデートを必要とするアクティブユーザーがいる限り、 最善の努力 で安定版ブランチをサポートします。
新しいメジャーバージョンがリリースされるたびに、私たちは以前の安定したブランチを長期サポートするリリースとし、そのブランチのユーザーが複雑なプロジェクトを新しいメジャーバージョンに移植できない場合には、できる限り発生した問題の修正を提供しています。これは 2.1 ブランチの場合であり、3.x ブランチの場合も同様です。
提供されているマイナーリリースシリーズでは、最新のバージョンのみがサポートを受けています。以前のバージョンで問題が発生した場合、githubで問題を報告する前に、最新のバージョンにアップグレードしてもう一度テストしてください。
バージョン |
リリース日 |
サポートレベル |
Godot 4.5 (master) |
2025年 第3四半期 (予定) |
|
Godot 4.4 |
2025年3月 |
|
Godot 4.3 |
2024年8月 |
|
Godot 4.2 |
2023年11月 |
|
Godot 4.1 |
2023年7月 |
|
Godot 4.0 |
2023年3月 |
|
Godot 3.7 (3.x) |
今のところETAはありません |
|
Godot 3.6 |
2024年9月 |
|
Godot 3.5 |
2022年8月 |
|
Godot 3.4 |
2021年11月 |
|
Godot 3.3 |
2021年 4月 |
|
Godot 3.2 |
2020年1月 |
|
Godot 3.1 |
2019年3月 |
|
Godot 3.0 |
2018年1月 |
|
Godot 2.1 |
2016年7月 |
|
Godot 2.0 |
2016年2月 |
|
Godot 1.1 |
2015年5月 |
|
Godot 1.0 |
2014年12月 |
|
印: 
完全サポート - 
一部サポート - 
サポートなし(終了) - 
開発版
Godotのプレリリース版は、実務に使用されることを意図したものではなく、ベストエフォートで提供されています。
参考
Godot 3.x から 4.x へのプロジェクトの移行手順については、Upgrading from Godot 3 to Godot 4 を参照してください。
新しいプロジェクトにはどのバージョンを使用すればよいですか？
Godot 4.x は将来 3.x がアップデートの配信が停止した後もサポートされるため、新しいプロジェクトには Godot 4.x を使用することをお勧めします。注意する点はサードパーティのドキュメントの多くが Godot 4.x 用にまだ更新されていないことです。 Godot 3.x 用に設計されたチュートリアルに従う必要がある場合は、別のタブで Upgrading from Godot 3 to Godot 4 を開いたままにして、どのメソッドの名前が変更されたかを確認することをお勧めします (特定のノードやメソッドを使用する場合、4.xでは名前が変更されているためスクリプトエラーが発生することがあります)。
プロジェクトで 4.x にない機能 (GLES2/WebGL 1.0 など) が必要な場合は、代わりに Godot 3.x を使用する必要があります。
新しいエンジンバージョンを使用するために、プロジェクトをアップグレードする必要がありますか?
注釈
プロジェクトの作業中にソフトウェアをアップグレードすることは本質的にリスクを伴うため、アップグレードを試みる前に、それがプロジェクトにとって良い選択肢であるかどうかを検討してください。またプロジェクトのバックアップを作成するか、バージョン管理を使用して、アップグレードが失敗した場合にデータが失われないようにしてください。
とはいえ、私たちはマイナーリリース、特にパッチリリースと既存のプロジェクトとの互換性を保つために最善を尽くしています。
一般的な推奨事項は、4.0.2 から 4.0.3 へのアップグレードなど、新しい パッチ リリースに従うようにプロジェクトをアップグレードすることです。これにより、バグ修正、セキュリティ更新、プラットフォームのサポート更新 (モバイルプラットフォームにとって特に重要) を確実に入手できます。また公式コミュニティでは最後のパッチリリースのみが継続的なサポートも受けられます。
マイナー リリースの場合は、ケースバイケースでアップグレードすることが得策であるかどうかを判断する必要があります。アップグレードプロセスを可能な限りシームレスにするために多大な努力を払ってきましたが、マイナーリリースには重大な変更が含まれる可能性があり、リグレッションのリスクも高くなります。マイナーリリースに含まれる一部の修正は、一部のバグを修正するために必要に応じてクラスの挙動を変更する場合もあります。これはドキュメントで 実験的 とマークされているクラスに特に当てはまります。
メジャー リリースでは多くの新機能が追加されますが、以前の既存の機能も削除され、ハードウェア要件が上昇する場合があります。またマイナーリリースと比較して、アップグレードにははるかに多くの作業が必要になります。そのためプロジェクトの現在の動作に満足している場合は、プロジェクトを開始したメジャーリリースを使い続けることをお勧めします。たとえば、プロジェクトが 3.5 で開始された場合、3.5.2 にアップグレードし、将来的には 3.6 にアップグレードすることをお勧めしますが、プロジェクトが 4.0 以降に付属する新機能を本当に必要としない限り、4.0 以降にはアップグレードしないことをお勧めします。
次のリリースはいつ？
Godotのコントリビュータはデッドラインに基づいて作業しているわけではありませんが、私たちは比較的頻繁にマイナーリリースを公開するよう努めています。
特に 4.0 の非常に長いリリース サイクルの後、私たちはより速いペースの開発ワークフローに軸足を移しており、4.1 は 4.0 の 4 か月後にリリースされ、4.2 は 4.1 の 4 か月後にリリースされています。
マイナーリリースを頻繁に行うことで、新機能をより迅速に (おそらく実験版として) リリースし、ユーザーからのフィードバックを迅速に取得し、それらの機能とその使いやすさを改善するために反復することができます。一般的なユーザーエクスペリエンスも、エンドユーザーへの道筋がより速くなることで、より着実に改善されます。
メンテナンス (パッチ) リリースは、非常に短い開発サイクルで必要に応じてリリースされ、現在の安定版ブランチのユーザーに、実際の現場で必要とされる最新のバグフィックスを提供します。
現在、次の3.xマイナーバージョンである3.7のリリース予定日はありません。現在の安定版である3.6は、Godot 3.xの最後の安定ブランチである可能性があります。Godot 3.xは、貢献者がメンテナンスを続ける限り、最善の努力に基づいてサポートされています。
エンジンのバージョン間における互換性の判断基準は何ですか？
注釈
このセクションは、ユーザーが特定のリリースに対してどの変更が安全であるかを判断するために、使用されることを目的としています。このリストはすべてを網羅しているわけではありません ( Godot の開発中に遭遇する最も一般的な状況の概要を説明しているにすぎません)。
以下の変更は、パッチリリースで許容されます:
視覚的または物理的なバグなどは、ほとんどのプロジェクトに大きな悪影響を及ぼさない方法でバグを修正します。 Godot の物理エンジンは決定論的ではないため、物理バグ修正は互換性を損なうものとはみなされません。バグの修正が多くのプロジェクトに悪影響を与える可能性がある場合は、バグ修正をオプションにする必要があります (例: プロジェクト設定や他の設定を使用するなど)。
新しいオプションのパラメータをメソッドに追加します。
エディターのユーザビリティの微調整。
後続の各パッチリリースで許可される修正については、より保守的になる傾向があることに注意してください。たとえば、4.0.1 は 4.0.4 よりも影響の大きい修正を受ける可能性があります。
以下の変更は、マイナーリリースで許容されますが、パッチリリースでは許容されません。
重要な新機能。
メソッドパラメータの名前の変更。 C# では、メソッドパラメーターを名前で渡すことができます (ただし、GDScript では渡せません)。その結果、C# を使用する一部のプロジェクトが壊れる可能性があります。
メソッド、メンバー変数、またはクラスの非推奨化。これは、非推奨フラグがクラス参照に追加されたことで行われ、エディターに表示されます。メソッドが非推奨としてマークされた場合、そのメソッドは次の メジャー リリースで削除される予定です。
デフォルトのプロジェクトテーマのビジュアルに影響を与える変更。
ユーザーの期待にさらに応えることを目的として、動作や出力を大幅に変更する不具合の修正。それに比べ、パッチ リリースでは、不具合のある動作に依存している可能性が高い既存のプロジェクトを壊したり、回避策を講じる必要がないように、不具合のある動作の維持を優先する場合があります。
視覚的な変化をもたらすパフォーマンスの最適化。
以下の変更は 互換性を破壊する とみなされ、新しいメジャーリリースでのみ実行可能です。
メソッド、メンバー変数、またはクラスの名前の変更または削除。
別クラスから継承させることによる、ノードの継承ツリーの変更。
既存のプロジェクトに影響を与えるような、プロジェクト設定値の、デフォルト値の変更。影響を新しいプロジェクトに限定したい場合は、プロジェクト管理者は、代わりに変更された
project.godotを作成する必要があります。
まだ Godot 5.0 には分岐していないため、現在、この類の互換性が破壊される変更をおこなうことは非推奨です。
注釈
メソッドのシグネチャーを何らかの方法で変更する場合 (オプションのパラメーター追加を含む)、GDExtension 互換のメソッドを作成する必要があります。これにより、既存の GDExtensions がパッチおよびマイナーリリースにおいても引き続き動作することが保証され、ユーザーが再コンパイルする必要がなくなります。詳細については、 Handling compatibility breakages を参照してください。