リリースの計画プロセス

  • [アーティクル]

特定のリリースに含める特定の機能をどのように選ぶかについて、よく質問を受けます。 このドキュメントでは、使用するプロセスについて説明します。 プロセスは、計画するためのより優れた方法が見つかるたびに進化し続けますが、一般的な考え方は変わりません。

さまざまな種類のリリース

リリースの種類によって、さまざまな種類の変更が含まれています。 これは、リリースの計画がリリースの種類によって異なることを意味します。

パッチ リリース

パッチ リリースでは、バージョンの "パッチ" 部分のみが変更されます。 たとえば、EF Core 3.1.1 は、EF Core 3.1.0 で見つかった問題を修正するためのリリースです。

パッチ リリースは、重大な顧客のバグを修正することを目的としています。 つまり、パッチ リリースには、新機能は含まれていません。 特別な状況を除き、パッチ リリースでは API の変更は許可されていません。

パッチ リリースで変更を実施するためのハードルは非常に高くなっています。 これは、パッチ リリースによって新しいバグを発生させないことが重要であるためです。 そのため、決定プロセスにおいては、高価値および低リスクが重要視されます。

次の場合、問題が修正される可能性が高くなります。

  • 複数の顧客に影響がある
  • 以前のリリースからの再発である
  • 問題が原因でデータが破損する

次の場合、問題が修正される可能性は低くなります。

  • 適切な回避策がある
  • 修正によって他の問題が発生する危険性が高い
  • バグが奥深い場所にある

このハードルは、長期サポート (LTS) リリースの有効期間において徐々に上がっていきます。 これは、LTS リリースでは安定性が重視されるためです。

問題を修正するかどうかについての最終的な決定は、Microsoft の .NET ディレクターによって行われます。

メジャー リリース

メジャー リリースでは、EF の "メジャー" バージョン番号が変更されます。 たとえば、EF Core 3.0.0 は、EF Core 2.2.x を大きく前進させたメジャー リリースです。

メジャー リリース:

  • 以前のリリースの品質と機能を改良することを目的としています
  • 通常、バグの修正と新機能が含まれています
    • EF Core の動作方法に対する根本的な変更となる新機能がある場合もあります
  • 通常、重大な変更が意図的に含まれています
    • 重大な変更は、理解が進むとともに EF Core を進化させるために必要なものです
    • ただし、顧客に影響を与える可能性があるため、重大な変更については慎重に検討を行います。 過去には、重大な変更をかなり積極的に行った部分もあるかもしれません。 今後は、アプリケーションを中断する変更を最小限に抑え、データベース プロバイダーや拡張機能を損なう変更を減らすことに努めています。
  • 多くのプレリリース レビューが NuGet にプッシュされています

メジャーまたはマイナー リリースの計画

GitHub 問題追跡

GitHub (https://github.com/dotnet/efcore) は、すべての EF Core 計画の信頼できる情報源です。

GitHub 上の問題には、次の情報があります。

  • 状態
    • Open は、未対応の問題です。
    • Closed は、対応された問題です。
      • 修正された問題にはすべて、closed-fixed のタグが付けられます。 closed-fixed のタグが付けられた問題は、修正されマージされていますが、リリースされていない場合があります。
      • その他の closed- ラベルは、問題を終了する他の理由を示すものです。 たとえば、重複するものには closed-duplicate というタグが付けられています。
  • 種類
    • Bugs は、バグを表します。
    • Enhancements は、新機能または既存の機能の改良された機能を表します。
  • マイルストーン
  • 投票
    • 投票は、ある問題が自分にとって重要であるということを示す、最善の方法です。
    • 投票するには、その問題に対して "上向きの親指" 👍 を追加するだけです。 たとえば、これらが投票数の多い問題です
    • また、そうすることで効果が生まれると思われる場合は、機能を必要とする具体的な理由についてコメントしてください。 「+ 1」などのコメントを付けても、効果は生まれません。

計画プロセス

計画プロセスには、最もリクエストが多い機能をバックログから取得する以上のことが含まれます。 これは、複数の関係者からのフィードバックを複数の方法で収集するためです。 その後、次に基づいてリリースを形づくります。

  • 顧客からのインプット
  • 他の関係者からのインプット
  • 戦略上の方向性
  • 利用可能なリソース
  • スケジュール

次のような質問を検討します。

  1. この機能を使用する開発者の数は? アプリケーション/エクスペリエンスをどの程度向上させますか? この質問に答えるために、多くのソースからフィードバックを収集します。問題についてのコメントと投票は、これらのソースの 1 つです。 重要な顧客との特定の契約は別のものです。

  2. この機能をまだ実装していない場合、ユーザーが使用できる回避策とは? たとえば、多対多のネイティブ サポートがないことを回避するために、多くの開発者は統合テーブルをマップすることができます。 当然ながら、すべての開発者がこれを実行するわけではありませんが、その多くは実行できます。そしてこれは決定の要因としてカウントされます。

  3. 他の機能を実装させるようにするなど、この機能の実装によって EF Core のアーキテクチャは進化しますか? 他の機能の構成要素として動作する機能は優先される傾向があります。 たとえば、プロパティ バッグ エンティティによって多対多のサポートを進めることができ、エンティティ コンストラクターによって遅延読み込みのサポートが可能になりました。

  4. この機能は拡張ポイントですか? 拡張ポイントは通常の機能よりも優先される傾向があります。なぜなら、開発者がこれらを使用して、それぞれの独自の動作をフックし、不足している機能を補うことができるためです。

  5. 他の製品と組み合わせて使用するときの機能のシナジーとは何ですか? .NET Core、最新バージョンの Visual Studio、Microsoft Azure など、その他の製品と共に EF Core を使用するエクスペリエンスを可能にする、または大幅に向上させる機能は、優先される傾向があります。

  6. 機能に取り組むために利用できるユーザーのスキルは何ですか? これらのリソースを最大限に活用する方法はありますか? EF チームの各メンバーおよびコミュニティの共同作成者は、異なる領域におけるさまざまなレベルの経験を持っているので、それに応じて計画を立てる必要があります。 GroupBy の変換や多対多など、特定の機能に取り組むために "全員の協力" が欲しくなる場合であっても、それは実用的ではありません。