kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update content/ja/blog/_posts/2024-01-15-SIG-Release-Spotlight/index.md 

Co-authored-by: nasa9084 <nasa9084@users.noreply.github.com>
This commit is contained in:
Shuhei Kawamura 2024-02-02 11:11:30 +09:00 committed by shukawam
parent ff8d9e1c6a
commit 9b442e1d51
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/ja/blog/_posts/2024-01-15-SIG-Release-Spotlight/index.md
View File

@ -19,7 +19,7 @@ SIG ReleaseはKubernetesの開発と進化において重要な役割を担っ
Kubernetesの新バージョンのリリースプロセスは、十分に構造化されたコミュニティ主導の取り組みです。私たちが従う特定の方法論やツールはありませんが、物事を整理しておくための一連の手順を記載したカレンダーはあります。完全なリリースプロセスは次のようになります： Kubernetesの新バージョンのリリースプロセスは、十分に構造化されたコミュニティ主導の取り組みです。私たちが従う特定の方法論やツールはありませんが、物事を整理しておくための一連の手順を記載したカレンダーはあります。完全なリリースプロセスは次のようになります：
- **リリースチームの立ち上げ**： 新しいリリースのさまざまなコンポーネントの管理を担当するKubernetesコミュニティのボランティアを含むリリースチームの結成から始めます。これは通常、前のリリースが終了する前に行われます。チームが結成されると、リリースチームリーダーとブランチマネージャーが通常の成果物のカレンダーを提案する間に、新しいメンバーがオンボードされます。例として、SIGリリースのリポジトリに作成された[v1.29チーム結成の課題](https://github.com/kubernetes/sig-release/issues/2307)を見てください。コントリビューターがリリースチームの一員になるには、通常リリースシャドウプログラムを通りますが、SIGリリースに参加する唯一の方法というわけではありません。 - **リリースチームの立ち上げ**： 新しいリリースのさまざまなコンポーネントの管理を担当するKubernetesコミュニティのボランティアを含むリリースチームの結成から始めます。これは通常、前のリリースが終了する前に行われます。チームが結成されると、リリースチームリーダーとブランチマネージャーが通常の成果物のカレンダーを提案する間に、新しいメンバーがオンボードされます。例として、SIGリリースのリポジトリに作成された[v1.29チーム結成のissue](https://github.com/kubernetes/sig-release/issues/2307)を見てください。コントリビューターがリリースチームの一員になるには、通常リリースシャドウプログラムを通りますが、それがSIGリリースに参加する唯一の方法というわけではありません。
- **初期段階**： 各リリースサイクルの最初の数週間で、SIG ReleaseはKubernetes機能強化提案（KEPs）で概説された新機能や機能強化の進捗を熱心に追跡します。これらの機能のすべてがまったく新しいものではありませんが、多くの場合、アルファ段階から始まり、その後ベータ段階に進み、最終的には安定したステータスに到達します。 - **初期段階**： 各リリースサイクルの最初の数週間で、SIG ReleaseはKubernetes機能強化提案（KEPs）で概説された新機能や機能強化の進捗を熱心に追跡します。これらの機能のすべてがまったく新しいものではありませんが、多くの場合、アルファ段階から始まり、その後ベータ段階に進み、最終的には安定したステータスに到達します。
- **機能の成熟段階**： 通常、コミュニティからのフィードバックを集めるため、実験的な新機能を含むアルファ・リリースを2、3回行い、その後、機能がより安定し、バグの修正が中心となるベータ・リリースを2、3回行います。この段階でのユーザーからのフィードバックは非常に重要で、この段階で発生する可能性のあるバグやその他の懸念に対処するために、追加のベータ・リリースをカットしなければならないこともあります。これがクリアされると、実際のリリースの前にリリース候補（RC）をカットします。このサイクルを通じて、リリースノートやユーザーガイドなどのドキュメントの更新や改善に努めます。 - **機能の成熟段階**： 通常、コミュニティからのフィードバックを集めるため、実験的な新機能を含むアルファ・リリースを2、3回行い、その後、機能がより安定し、バグの修正が中心となるベータ・リリースを2、3回行います。この段階でのユーザーからのフィードバックは非常に重要で、この段階で発生する可能性のあるバグやその他の懸念に対処するために、追加のベータ・リリースをカットしなければならないこともあります。これがクリアされると、実際のリリースの前にリリース候補（RC）をカットします。このサイクルを通じて、リリースノートやユーザーガイドなどのドキュメントの更新や改善に努めます。
- **安定化段階**： 新リリースの数週間前にコードフリーズを実施し、この時点以降は新機能の追加を禁止します。メインリリースと並行して、私たちはKubernetesの古い公式サポートバージョンのパッチを毎月カットし続けているので、Kubernetesバージョンのライフサイクルはその後数ヶ月に及ぶと言えます。完全なリリースサイクル全体を通して、リリースノートやユーザーガイドを含むドキュメントの更新と改善に努めます。 - **安定化段階**： 新リリースの数週間前にコードフリーズを実施し、この時点以降は新機能の追加を禁止します。メインリリースと並行して、私たちはKubernetesの古い公式サポートバージョンのパッチを毎月カットし続けているので、Kubernetesバージョンのライフサイクルはその後数ヶ月に及ぶと言えます。完全なリリースサイクル全体を通して、リリースノートやユーザーガイドを含むドキュメントの更新と改善に努めます。