Go Wiki: 標準ライブラリとツールチェーンへのリスクの高い変更に関するガイド

リスクの高い変更を行う際は、特に注意してください。念のため

診断が困難な障害を引き起こす可能性のある変更（例えば、ランタイム、GC、コンパイラ、リンカ、TLS、その他の低レベルコンポーネントの変更、または本番ワークロードの下で慣らし運転が必要な複雑な変更）、あるいは元に戻すのが困難な多数のCLを必要とする変更（例えば、大規模なCLやCLのスタック）は、リスクの高い変更とみなされます。

リスクの高い変更に取り組む予定がある場合は、以下を行ってください

1. 変更全体を元に戻すのが絶対に簡単でない限り、新しいコードパスをブール値フラグで保護してください。このフラグには `go126` というプレフィックスを付け、古い実装に素早く切り替えるために使用できます。これは、例えば `const go126UseEvenBetterLinker = true` のような単純なブール定数で構いません。このようなフラグは、文字列 `go126` を単純にgrepすることで見つけられる必要があります。そうすれば、見落としなく見つけることができ、Go 1.27サイクルになったときにクリーンアップできます。
2. あなたの変更について、以下の質問にどう答えるかを検討してください
   • 計画している変更はどれくらいリスクが高いですか？
   • それが意図どおりに機能していることをどのように知りますか？
   • それが意図どおりに機能していると確信するまでに、どれくらいの製品テストが必要ですか？
   • 保持/元に戻すの決定はいつ行われるべきですか？
3. Go 1.26マイルストーンに、リリースブロッカーラベルを付けてトラッキング課題を作成してください。この課題は、機能の進捗を追跡し、Go 1.26の最終決定を下すために使用されます。