Go Wiki: Go-Release-Cycle

Table of Contents
概要タイムラインリリースメンテナンスフリーズ例外歴史的な注意

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

短縮リンク: https://go.dokyumento.jp/s/release。

概要¶

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

バージョンの最初のリリース後、重大なバグとセキュリティ問題を修正するマイナーリリースでサポートされます。

タイムライン¶

現在のリリースサイクルは、毎年1月中旬と7月中旬に開始するように調整されています。リリースサイクルの目標マイルストーンは、以下に説明するとおりです。品質の高いリリースを提供しながら、可能な限り目標を達成するように努めます。

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

release

1月/7月1週目: リリースの計画が開始されます。¶

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

例: Go 1.20

1月/7月3週目: リリース作業が開始されます。¶

前のリリースが最終的な安定化期間に入ると、ツリーは一般的な開発のために開かれます。この期間中はあらゆる種類の開発が歓迎されます。大規模または特にリスクの高い変更は、開発期間の終了前に十分に着地させ、それらで発生する問題を修正する時間を与えることが望ましいです。

5月/11月4週目: リリースフリーズが開始されます。¶

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

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

リリースサイクルのこの部分は、テストと発見されたバグの修正により、リリースの品質向上に重点を置いています。ただし、すべての修正は、可能な修正の利点と、リリースでテストされていないコード（修正）を持つことのコストとのバランスを評価する必要があります。リリースサイクルの初期には、バランスは修正を受け入れる傾向があります。リリースサイクルの後半では、修正が低リスクでかつ高い報酬をもたらすというケースが提示されない限り、バランスは修正を拒否する傾向があります。

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

フリーズが開始されて間もなく、ほとんどすべての既知のバグは修正されるか、明示的に延期されている必要があります（次のリリースまたは無期限に）。残りは通常、リリースブロッカーとして追跡され、緊急に取り組む必要があります。

6月/12月2週目: リリース候補1が発行されます。¶

リリース候補は、実際のリリースのビットに可能な限り近いものであることを意図しています。リリース候補の発行は、Goチームがツリーに重大なバグがないと確信していることを示すものです。特に、GoogleはGoの開発バージョンを継続的に追跡しているため、リリース候補が発行されるまでに、その近似版はGoogleで少なくとも1、2週間は本番環境で実行されています。

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

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

繰り返しますが、リリース候補は可能な限りバグがないようにすることを意図しています。組織は、適切な組織固有のテストの後、本番環境設定にデプロイすることをお勧めします。

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

7月/1月3週目: 次のリリースに向けた作業が開始されます¶

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

8月/2月2週目: リリースが発行されます。¶

ついに、リリース自体です！

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

リリースがスムーズに進み、時間が余ったとしても、スケジュールどおりに進むことを推奨します。追加のテストはリリースの安定性を向上させるだけであり、Goリリースに取り組む開発者は、コードの変更が再び流れ込む前に、次のリリースについて考え、計画する時間が増えます。

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

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

リリースメンテナンス¶

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

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

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

フリーズ例外¶

フリーズポリシーで許可されているFix CLにはフリーズ例外は必要ありません。

フリーズの例外は、フリーズ前にGoリリースチームに伝え、明示的に承認される必要があります。例外をリクエストする場合は、問題トラッカーに「[freeze exception]」というサフィックスを付けて問題を報告し、「CC @golang/release」を含めてください(例)。フリーズ後の変更を許可しないことを強く推奨して、ケースバイケースでリクエストに対処します。

歴史的な注意¶

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

このコンテンツは、Go Wikiの一部です。