Go Wiki: Go-Release-Cycle

このwikiページはGoチームによって管理されています。直接変更を加えるのではなく、コメントはgolang-devへ送信するか、課題を提出してください。

ショートリンク: https://go.dokyumento.jp/s/release。

概要

Goは6ヶ月ごとにリリースされます。各リリースサイクルは、約4ヶ月の開発フェーズと、その後の3ヶ月間のテストと調整期間であるリリースフリーズに分かれています。すべてが順調に進めば、前のリリースが出荷される前に次のリリースの作業が始まり、約1ヶ月の重複期間が生じます。

バージョンの初回リリース後、深刻なバグやセキュリティ問題を修正するマイナーリリースによってサポートされます。

タイムライン

現在のリリースサイクルは、毎年1月中旬と7月中旬に開始するよう調整されています。リリースサイクルの目標マイルストーンは以下の通りです。品質の高いリリースを提供しながら、できるだけ目標に近づくよう努めています。

チームが準備する時間を確保し、予期せぬ問題に対処するため、リリース作業は週の初めまたは中頃に行うことを好みます。つまり、正確な日付は年によって異なるため、マイルストーンは特定の月の週として指定されます。第1週はその月の最初月曜日から始まる週です。すべての日付は、その年の祝日のタイミングによって変更される可能性があります。

1月/7月 第1週：リリースの計画が始まる。

今後のリリースサイクルの主要な作業計画はgolang-devで発表されます。

例：Go 1.20

1月/7月 第3週：リリース作業が始まる。

先行リリースが最終安定化期間に入ると、ツリーは一般的な開発のために開放されます。この期間中はあらゆる種類の開発が歓迎されます。大規模な変更や特にリスクの高い変更は、開発期間の終了よりかなり前に着手し、発生する可能性のある問題を修正する時間を確保することが望ましいです。

5月/11月 第4週：リリースフリーズが始まる。

このマイルストーンは、リリースサイクルの第2部、リリースフリーズの開始です。リリースフリーズは、メインリポジトリ全体だけでなく、リリースに含まれるバイナリ（特にvetとそのtoolsサブリポジトリ内のすべての依存関係）をビルドするために必要なサブリポジトリ内のコードにも適用されます。

フリーズ期間中は、バグ修正、テストのみの変更、ドキュメントの更新のみが受け入れられます。例外的にフリーズ期間中に新しい作業が行われることもありますが、それはごくまれな状況で、通常は変更が提案され、期限前に承認されていた場合に限られます。そのような変更は低リスクでなければなりません。以下のフリーズ例外を参照してください。

リリースサイクルのこの部分は、テストと発見されたバグの修正によってリリースの品質を向上させることに重点を置いています。しかし、すべての修正は、可能な修正の利点と、リリースに含まれるテストされていないコード（修正）のコストを比較して評価する必要があります。リリースサイクルの初期段階では、修正を受け入れる傾向が強く、リリースサイクルの後期では、修正が低リスクかつ高リターンであると主張できる場合を除き、修正を拒否する傾向が強くなります。

サイクル後半に適した低リスクの変更の例としては、ドキュメントの変更や、現在のリリースで導入されている新機能の修正（以前のリリースと比較してデグレードを導入する可能性がないため）などがあります。

フリーズ開始後まもなく、既知のバグはほとんどすべて修正されるか、明示的に延期される（次のリリースまでか、無期限に）はずです。残りのバグは通常、リリースブロッカーとして追跡され、緊急に作業されるべきです。

6月/12月 第2週：リリース候補1号が発行される。

リリース候補は、実際のリリースバイナリに可能な限り近いものです。リリース候補の発行は、Goチームがツリーに致命的なバグがないと高い確信を持っていることを示すものです。特に、GoogleはGoの開発版を継続的に追跡しているため、リリース候補が発行される頃には、その近似版がGoogleのプロダクション環境で少なくとも1〜2週間稼働していることになります。

リリース候補が発行された後、ドキュメントの変更と致命的なバグに対処するための変更のみが行われるべきです。一般的に、この時点でのバグ修正の基準は、マイナーリリースでのバグ修正の基準よりもわずかに高くなります。既知だが非常にまれなクラッシュを伴うリリースを発行するよりも、新しく、しかし本番環境でテストされていない修正を伴うリリースを発行することを好む場合があります。

致命的なバグが報告され修正された場合、追加のリリース候補が発行される場合がありますが、通常は2週間に1回以上は発行されません。

繰り返しになりますが、リリース候補は可能な限りバグのないものであることを意図しています。組織は、適切な組織固有のテストを行った後、本番環境にデプロイすることが推奨されます。

リリース候補と最終リリースとの間の穏やかな期間は、追加のテストや次のリリースの議論（上記の計画マイルストーンを参照）に適した時期です。

7月/1月 第3週：次のリリースの作業が始まる

現在のリリースが安定化されている間に、ツリーは次のリリースの作業のために再び開放されます。この期間中、現在のリリースを対象とした修正は、リリースブランチにcherry-pickされる必要があります。マイナーリリース向けのcherry-pickとは異なり、これらの変更はバックポートの問題を必要とせず、リリースチームによる承認も必要ありません。フリーズポリシーで許可されている限り、他のCLと同様にレビューおよび提出できます。

8月/2月 第2週：リリースが発行される。

いよいよリリース本番！

リリースは、最後のリリース候補から大きな変更を含めるべきではありません。リリース内のすべてのコードが十分にテストされていることが重要です。リリースを発行することは、リリース前のテストによって、ツリーが致命的なバグがないというリリース候補の高い信頼性が確認されたことを示します。

たとえリリースがスムーズに進み、時間的余裕があったとしても、スケジュール通りに進めることを好みます。追加のテストはリリースの安定性を向上させるだけでなく、Goリリースに携わる開発者が、コードの変更が再び殺到し始める前に、次のリリースについてじっくり考え、計画する時間を与えることにもなります。

最終リリースが発行される頃には、GoogleはこのバージョンのGoを約2ヶ月間使用していることになります。Googleでの成功した使用は問題がないことを保証するものではありませんが、私たちの経験では、リリースの品質向上に確かに役立っています。他の組織にも、可能な限り積極的にリリース候補をテストし、発見した問題を報告することを強く推奨します。

リリースが安定したら、コードレビューや新しいコードの提出を含む次のリリースの作業を開始でき、サイクルが繰り返されます。リリースが遅れる場合、次のリリースの作業も遅れる可能性があることに注意してください。

リリースメンテナンス

マイナーリリースは、回避策がない1つ以上の重大な問題（通常は安定性またはセキュリティに関連するもの）に対処するために発行されます。リリースに含まれるコード変更は、特定の重大な問題の修正のみです。重要なドキュメントのみの変更や安全なテスト更新（テストの無効化など）も含まれる場合がありますが、それ以上は含まれません。マイナーリリースは、可能な限り後方互換性を維持し、新しいAPIは導入しません。

Go 1.x向けの（セキュリティ問題を含む）問題に対処するためのマイナーリリースは、Go 1.x+2がリリースされると停止します。セキュリティアップデートの詳細については、セキュリティポリシーを参照してください。

MinorReleases wikiページも参照してください。

フリーズ例外

フリーズポリシーで許可されている修正CLは、フリーズ例外を必要としません。

フリーズに対する例外は、フリーズ前にGoリリースチームに伝えられ、明示的に承認されなければなりません。例外を申請したい場合は、課題トラッカーに「[freeze exception]」を接尾辞として含む課題を提出し、「CC @golang/release」（例）を含めてください。フリーズ後の変更は許可しないという強い方針のもと、個々の要求に対処します。

歴史的注記

開発期間が短いこのスケジュールのバージョンは、もともと2016年のGo 1.7リリースで採用されました。長年にわたる困難なリリースを経て、2022年と2023年のテストとプロセスの改善により、1.19リリースが適時に行われました。1.20では、開発期間がフリーズの遅延と早期の解除により拡大されました。これらの変更は1.21リリースで正式化されました。私たちは今後も予定通りに出荷を続けることを予想しています。