モジュールはどのように緑、黄、赤のリリースを考え出しますか？

ご存知のとおり、drupal.orgで「Recommended Release」とマークされているモジュールがすべて本当に安定しているわけではありません。実際、いくつかのモジュールは、ある種の永続的なリンボ状態で、永続的にベータとマークされています。何百ものサイトが毎日それらを使用する場合でも。

リリースに「推奨」（緑）、「その他」（黄色）、または「開発」（赤）のマークを付けるために、モジュールのどのような標準またはベストプラクティスをメンテナーまたはコントリビューターとして使用していますか？ベータ版、アルファ版、または安定版にマークを付けるときに何を使用しますか？

提供できるアドバイス、ヘルプ、またはドキュメントを事前にありがとうございます。

注：これらの標準の多くは、コーディングまたはプロジェクト開発の一般的な標準である場合があります。私は、Drupalモジュールで具体的に使用されている方法または標準が、一般化できる場合でも、具体的に知りたかっただけです。

これらの標準の多くは、コーディングまたはプロジェクト開発の一般的な標準です。

Drupalにはこのための標準はありません。モジュールの所有者の最善の意思に任されています。

私の個人的な哲学は：

• テスト環境でテストした場合、またはすべてのテストケースに合格した場合は、ベータ版またはリリース候補をリリースします。
• 私自身、少なくとも3つの異なる実際のプロジェクトで（バージョンの）モジュールを正常に実装した場合にのみ、安定版をリリースします。または、私が知っている誰かが私の基準を持っている場合、それを行い、報告します。
• モジュールを完成させることができます。もう追加の作業は必要ありません。機能セットで制限され範囲が定められているものは、安定していて予測可能です。このようなモジュールには、バグ修正、機能要求、タスクは必要ありません。

実際には、これは非常に少数のリリースを意味しますが、行われたリリースはほとんど誰にも影響を与えません。その結果、実際には何もリリースされません。

これの背後にある私の推論は次のとおりです。

• 問題のキューに入っている人は、適切にテストすることはほとんどできません。機能を適用し、修正またはパッチを当て、f5を押し、機能することを確認して、「はい、私にとっては+1です」と言います。「動作しているようです」は「固定されている」とは異なります。信頼できるテストが必要です。そうしないと、変更をテストしなかった残りの人が、何か問題があると報告する問題が発生します。今すぐ修正する必要があります。
• モジュールがさまざまな状況や環境で実装された場合にのみ、実際の経験が得られます。ほとんどの場合、2番目の実装では、いくつかの中央APIを書き換える必要があるか、いくつかの有用なパラメーターを忘れたか、または単にいくつかの機能の必要性について誤った考えを持っていたことがわかります。現実世界での展開後にのみ、何かが安定していると見なすことができます。そうでなければ、それは理論的には安定しているだけです。
• サイトの開発者とメンテナー、モジュールのユーザーは、新しいリリース、セキュリティリリース、新しいバージョンに対応するために（私が知っている他のどのソフトウェアよりもはるかに）多大な労力を費やす必要があります。その努力（および予算と時間）に対する救済は大いに歓迎されるべきです。

バグを見つけた場所で使用するモジュールがある場合、最善の方法は問題を報告することです。さらに良いのは、誰かがその問題のパッチを書いた場合、そのパッチはその機能を必要とする開発者が書いたり、そのパッチの作成を後援した開発者が書いたりできることです。Contribのメンテナは通常、多くのモジュールを保守します。モジュールを作成すると、自動的にメンテナになります。言うまでもなく、これにより多大な負担がかかるため、パッチの作成、パッチのスポンサー、またはレビューを行う人々の支援が常に必要です。

drupal.orgでリリースを維持している場合、「サポートされている」チェックボックスがあり、これを有効にすると推奨リリースが表示され（緑）、「スナップショットリリースを表示」も有効にすると開発リリースが表示されます（赤）モジュールのメジャーバージョンが複数ある場合（6.1および6.2）、推奨リリースセクション（緑）に含めるバージョンを選択できます。ベータ版と通常のリリースのみが「推奨」セクション（緑）に移動し、それより下位のリリースは「その他のリリース」セクション（黄色）に表示されます。

ベータ、rcs、devについては、人気に依存し、モジュールがimoを埋めるニッチです。

Earlがデータ損失の問題があった公式バージョンのビューを公開した場合、インターネット全体が機能しなくなる可能性があります。

ただし、比較的人気のない（1,000ユーザーを超える）小さなモジュールがあり、定期的なバグ修正のみを行っている場合は、ベータ版やRC版ではなく、新しいリリースを作成する方が合理的です。

あなたがいくつかの大きな変更をしたか、たくさんのチャーンを見たことがわかっているなら、より徹底的にテストしてください。

データ損失の永続性を認識しているため、DBを変更したりupdate（）フックを発行したりするときに、beta / rcをテストしてロールする傾向があります。小さなバグ修正を世界中ですばやく再ロールして再リリースできますが、サイトのデータを再作成できます。

お役に立てば幸いです。