前説
Godot は開発者の数がそれなりに多い OSS であるため、頻繁にバージョンのアップデートが発生します。ユーザーとしてはプロジェクトを進めている上で、どこでバージョンを上げるか悩む事があるでしょう。
もちろん、アップデートのタイミングはユーザーに委ねられるのですが、Godot のコア開発のサイクルを把握しておくことで、アップデート時に問題が発生する事を防いだり、迅速なバグ修正が可能になる場合があります。
それでは、どのようなタイミング・判断で Godot をアップデートすべきかという事について、Godot の開発サイクルという観点から考えてみましょう。
Godot の開発サイクル
ステージ
現在、Godot は各バージョンごとに以下の4つのステージを設けています。
これらはソフトウェア開発における共通した概念ですが、簡単に見ていきましょう。
dev
- 新規機能の追加や、互換性の破壊が発生しうるリファクタリング（リワーク）などが行なわれるステージ
- 機能追加の Pull Request を送信するのに適した時期
beta
- 新規機能の追加はよほどの事がない限り行なわれず、安定化を図るステージ
- dev で追加された新規機能のテストや修正を行なう時期
RC
- 新規機能の追加は決して発生せず、バグ修正に集中するステージ
- 次の dev の準備期間でもあるため、機能追加の提案（proposal）を送信するのに適した時期
stable
- いくつかのバグへの対処は不定期的に行なわれるが、大きな変更はこれ以上行なわれないステージ
コア開発者の動き
上記のステージがどのように Godot のコア開発のサイクルに割りあてられているか、図で見てみましょう。
ここで、コア開発者の実際の動きを考えると、これらのステージを大きく２つに分けることができます。
stable / dev
上記の図から分かるように、stable バージョンが出た時点で次の dev ステージが開始されるため、stable はそれ専用の開発期間を実質的に持ちません。前の stable に対するバグ修正はその修正が単純なものである場合、次のバージョンから拾い上げる（cherry-pick）ようにして適用され、それらがある程度溜まったらパッチリリースを 4.3.stable に対して 4.3.1.stable というように行ないます。
ここで注意してほしいのが、dev 期間は前バージョンの stable のバグ対応期間ではあるのですが、中の人たちは主に新規機能の開発を行なっている状態になります。つまり、この時期にバグ報告をしても迅速な対応を行なうことはできません。
もちろん、stable が出た直後は実際に利用するユーザーが増えるため、ある程度はバグ対応を優先しますが、その優先度は徐々に下がっていきます。特に dev 期間から beta 期間に切り替わる時期は新規機能追加の〆日が近いことを意味するため、コーディングやレビューに集中している場合が多く、issue を見る暇もないことがあります。
beta / RC
beta と RC はどちらもバグ修正に集中するステージであるという点では、ほぼ違いがありません。RC は stable を出す予告みたいなもので、バグ報告が少なくなればその次には stable になります。
これらの期間中、開発者は直前の dev で追加された機能に対するバグの監視に目を光らせているため、もしユーザーがプロジェクトを移行して問題が出た場合、issue に報告すれば可及的速やかな対応が行なわれます。
つまり、もし Godot をアップデートする予定がある場合は、beta もしくは RC の期間にプロジェクトをアップデートしてテストを行なう事が推奨されます。注意としては、互換性の破壊を伴う可能性があるため、テストする場合はプロジェクトのバックアップをとることを忘れないでください。
ちなみに、これらの期間に送られた機能追加の PR は次の dev に持ちこされます。つまり、RC 期間の後半に送信された PR は次の dev でレビュー期間を長くとれるため、大きめの機能追加の PR や提案がある場合は RC 期間の後半にそれらを送るのがよいといえます。ただし、それらが現在進行中のバージョンに含まれる事は決してないため、それを RC の次の stable に割り込ませることを要求するような行動はつつしみましょう。
アップデート先を検討するためのフローチャート
上記のことから、アップデートの検討時は、以下のようなフローでアップデート先を判断する事が推奨されます。
つまるところ、バグに遭遇したかめぼしい新機能があるなら最新の dev/beta/RC へ、それ以外はどこかの stable にアップデートするかアップデートしない、という感じになります。当たり前ですね。
ちなみに図には書いてませんが、現在 dev/beta/RC を利用している状態で同マイナーバージョンの stable が出ている場合、stable にアップデートしない理由はないため（よほどのバグが stable で新たに発生していない限り）早めにアップデートする事を推奨します。
おわりに
当前のことを記事にした理由は、もっと多くの Godot ユーザーに beta や RC を触ってもらい、テストして欲しいという事をアピールしたかったからです。
自分で beta や RC を触っていない場合、 stable が自身にとって安定しているかどうかは beta や RC 時点での他のユーザーからのフィードバックに依存することになります。
また、 beta や RC を触ったとしても、そこでバグを見つけた時に GitHub への報告がなければ、そのバグが stable に持ちこまれる可能性が十分にあります。それが望ましくない場合、もし他の人がバグをまだ報告していないのであれば、自分でバグを報告する必要があります。
つまり、Godot を快適に使おうとする上では、受動的ではなく能動的な動きが求められることになりますが、ゲーム開発者という何かを発信する側の人間である以上、そのような動きが求められるのは必然的なことなのかもしれませんね。