リリースマネージャーのガイドライン¶
リリースマネージャーの目的は、スムーズなリリースを確保することです。この目的を達成するには、以下について調整する必要があります。
- Ansible GitHub リポジトリー でコミット権限を持つ開発者
- コミット権限のない貢献者
- コミュニティー
- Ansible ドキュメントチーム
- Ansible Tower チーム
プレリリース: 何を/なぜ¶
プレリリース版はテスターを集めるために存在します。プレリリースは、ソース管理からの実行に不安を感じているユーザーに、初期バージョンのコードを手に入れてテストをしたり、フィードバックを行う手段を提供します。リリースに関する適切なフィードバックを確実に得るには、リリースに対する主要な変更がすべてプレリリースに組み込まれているようにする必要があります。テスト担当者には、最終リリースの前にこれらの変更をテストする時間が与えられる必要があります。プレリリースとプレリリースの間に、1 つのバージョンをインストールしてテストするのに十分な時間を確保するのが理想的です。そうすれば、最新バージョンをインストールするよりも、新しいコードを使用することに多くの時間を費やすことができます。
テスターにとって適切な期間は、おそら 2 週間程度です。ただし、3 ~ 4か月の開発サイクルを機能させるには、この期間を 1 週間に短縮します。これより短くなると、コードを実行する代わりにコードのインストールに多くの時間を費やしてしまう可能性があります。ただし、時間的な制約がある場合は (リリース日がずれないようにするには)、ユーザーにテストする時間を与えるために変更を保留するよりも、新しい変更を加えてリリースする方が良いでしょう。リリースされていないものはテストできないため、たとえより頻繁にインストールしなければならないと思われる場合でも、その tarball は公開すべきです。
ベータリリース¶
ベータリリースでは、バグが存在していることが認識されています。これらの修正は今後も受け入れていきます。私たちはこれらの修正を確認しますが、場合によっては侵襲的であったり、コードの他の領域を不安定にする可能性があります。
ベータ版では、機能の提出は受け付けなくなります。
Release Candidate (リリースの候補)¶
リリース候補では、既知のすべてのブロッカーを修正しました。残っているバグ修正は、リリースから除外しても構わないと考えています。この時点で、他にもブロッカーバグが潜んでいないかどうかを判断するために、ユーザーテストを行う必要があります。
ブロッカーバグとは、一般的にユーザーに重大な問題を引き起こすバグのことです。リグレッションは、現在のユーザーの Ansible の使用方法に支障をきたすため、ブロッカーと見なされる可能性が高くなります。
リリースマネージャーは、新しいリリースのブロッカーの修正を選択します。また、リリースマネージャーは、コードの孤立した部分のバグ修正を受け入れるか、次のマイナーリリースに延期するかを選択します。単独では、ブロッカー以外のバグは新しいリリースのトリガーにはなりません。ブロッカーのバグにより新しいリリースを作成する必要がある場合にのみ、次のメジャーリリースになります。
最後の RC は可能な限り最終版に近いものにしてください。以下の点が変更される可能性があります。
- バージョン番号が自動的に変更され、 プレリリースのタグが削除されるとバージョンが異なります。
- テストおよび
docs/docsite/はランタイムを破損しないため、本当に必要であれば変更しても構いません。 ただし、リリースプロセス時に目に見える破損を引き起こす可能性がある場合は、 リリースマネージャーが拒否する可能性があります。
Note
特別な事情がない限り、(bin/、lib/ansible/、および setup.py の) コードは同じでなければなりません。特別な事情がある場合、リリースマネージャーは、コードをテストしたいグループ (Tower チームなど) に通知する責任があります。
Ansible リリースプロセス¶
リリースプロセスは、リリース中に簡単に更新できるように、別のドキュメント に保存されています。これを編集するためのアクセス権が必要な場合は、現在のリリースマネージャーに追加を依頼してください。