このドキュメントは、Bundlerプロジェクトを統括するために使用されるポリシーとプロセスを記録しようとする試みです。これは固定されたものではなく、状況に応じて進化する可能性があります。
これらのポリシーは、これらの目標を適用する方法の例として意図されており、あらゆる例外的なケースや抜け穴を網羅することはできないことを認識しています。ポリシーがこれらの目標と矛盾する場合、目標が優先されます。
Bundlerは完全な下位互換性を目指しています。つまり、バージョン1.xで動作したものは、1.yと1.zでも動作し続けるべきです。それが2.xでも動作するかどうかは別問題です。常にうまくいくとは限りませんし、様々な破損の間で選択を余儀なくされる状況もあるかもしれませんが、互換性は私たちにとって非常に重要です。インフラストラクチャは可能な限り予測可能なものでなければなりません。
2022年8月現在、Bundlerチームは機能とバグ修正を2.3.xバージョンとしてリリースしており、例外的に、デフォルトでサポートされているRuby（Bundler 2.1（Ruby 2.7付属）、Bundler 2.2（Ruby 3.0付属））と共にリリースされた古いシリーズへのセキュリティ修正をバックポートすることがあります。
2022年8月現在、Bundlerは下位互換性の理由から、Ruby 2.3まで遡ってRubyとRubyGemsのバージョンをサポートしています。古いRubyのサポートを終了しても何も壊れないようにするためのいくつかの改善が導入されているため、2022年クリスマスに古いRubyのサポートを終了することを目指しており、それ以降はRubyコアチームのサポートポリシーにさらに密接に追従します。
これらのポリシーは、特定の修正が必ずバックポートされるという保証ではありません。代わりに、これは、変更を行う際に考慮しなければならないRuby、RubyGems、およびBundlerのバージョンの上限を設定する方法です。制限がない場合、バージョンの数は時間の経過とともに指数関数的に増加し、すぐに管理できなくなり、メンテナーの燃え尽き症候群につながります。それを避けたいと思っています。
tl;dr：メジャーリリースは約年に1回、マイナーリリースはドキュメント付きの完成した機能に対して、パッチリリースはコミットされたバグ修正に対して。
パッチ（バグ修正）リリースは、一般的にできるだけ早く行う必要があります。単一のバグ修正PRに対するパッチリリースは完全に問題ありません。
マイナー（機能）リリースは、少なくとも1つの新しい機能が準備できたらいつでも行うことができますが、必ずしも行う必要はありません。マイナーバージョンリリースは、必要に応じて主要バージョンのマニュアルページとドキュメントのウェブサイトを更新する必要があり、それぞれに独自の「新機能」セクションを含める必要があります。
メジャー（破壊的変更）バージョンリリースは、年に1回を超えて行うべきではなく、そのメジャーバージョン専用のドキュメントウェブサイトの新しいセクションを含める必要があります。理想的には、メジャーリリースは、2月または3月にRubyのバージョンがサポートを失った後に実行され、RubyコアチームによってサポートされるRubyバージョンと同期を保つのに役立ちます。
古いRubyバージョンのサポートを終了すること以外の破壊的変更は、可能な限り回避する必要がありますが、メジャーリリースに含めることができます。一般的に、破壊的変更には、破壊的変更が有効になる前に、少なくとも1つのメジャーバージョンの非推奨警告（期間1年）を含める必要があります。
Bundlerの使用経験に意外なことがあってはいけません。ユーザーが驚いた場合、私たちが何か間違ったことをしており、修正する必要があります。「ユーザーエラー」はなく、UXデザインの失敗のみが存在します。警告には、常に解決するための実行可能な手順を含める必要があります。エラーには、ユーザーがデバッグを試みるのに役立つ手順、参考資料、その他の情報を含める必要があります。
既存の動作を変更することもまた、意外なことです。ユーザーの驚きを軽減することが下位互換性のない変更につながる場合、その変更には、破壊的変更が行われる前に、少なくとも1つのメジャーバージョンの非推奨警告を含める必要があります。
誰でも問題を開いたり、問題にコメントしたりできます。「私も同じです」のような役に立たないコンテンツを含む問題のコメントは削除される場合があります。
助けを求めるために問題を開いても、最終的には助けが得られるかもしれませんが、Stack Overflowに投稿するか、Bundler Slackで質問する方が、助けが早く届く可能性が高いです。
問題はできるだけ早く処理されますが、時間がかかる場合があります。問題の再現に使用できるスクリプトを含めることは、メンテナーがあなたを助けるための素晴らしい方法です。可能であれば、問題に対する失敗するテストを作成すると、さらに役立ちます。
誰でもBundlerに貢献できます。寄稿されたコードは、既存のコードベースと同じライセンスの下でリリースされます。
プルリクエストは、マージするにはテストに合格する必要があります。コードの変更には、新しい動作に対するテストも含まれている必要があります。コミットの圧縮は必須ではありません。
すべてのプルリクエストでは、以下を説明する必要があります。
大規模な変更は、より完全に書き出し、他の人に見てもらい、議論することで、多くの場合、メリットがあります。Bundler RFCリポジトリはそのための最適な場所です。
常にプルリクエストを作成し、主要ブランチに直接プッシュしないでください。可能であれば、自分以外の人からコードレビューとマージ承認を得るようにしてください。
6ヶ月以上定期的に貢献してきた貢献者（またはマイナーリリースのために完全に新しい機能を実装した貢献者）は、メンテナチームに参加する資格があります。既存のメンテナによって拒否されない限り、これらの貢献者にはメンテナチームへの参加が依頼されます。参加を受け入れると、新しいメンテナはメンテナプレイブックの閲覧、プルリクエストの承認、新バージョンのリリースの権限が付与されます。
まず、Bundlerのポリシーとそれらのポリシーの執行は、Bundlerの行動規範に従属します（矛盾する場合）。最優先事項は、人間を尊重と共感を持って扱い、プロジェクトのガイドラインを理解し、それに従うことです。
独自のポリシーを実行することになると、私たちは皆、最善を尽くそうとしている普通のヒトです。ポリシーや目標に従わない時もあるでしょう。現実の行動とこれらのポリシーや目標の間に食い違いに気づいたら、お知らせください！行動とポリシーが一致し、ポリシーが目標を体現するようにしたいと考えています。
ポリシーは固定されたものではなく、ポリシー違反がプロジェクトの目標の精神に合致していると判断された場合は改訂される場合があります。同様に、プロジェクトの目標の精神に反する行為はポリシー違反とみなされ、執行措置が取られます。私たちはルールにこだわることに興味はなく、必要に応じて行動を起こして、誰もが安全で包括的なと感じられるようにします。
Bundlerチーム全体に問題を報告することに問題がない場合は、team@bundler.ioにメールを送信してください。何らかの理由でチーム全体に報告することに問題がある場合は、メンテナチームリストを確認し、メール、Twitter、またはSlackを使用して選択したメンテナに報告してください。ポリシーまたは目標に違反した者は、プロジェクトの目標に従う方法で問題を解決するために、チーム（および要求があれば報告者）と協力することが期待されます。