リリースの計画プロセスRelease planning process

特定のリリースに含める特定の機能をどのように選ぶかについて、よく質問を受けます。We often get questions about how we choose specific features to go into a particular release. このドキュメントでは、使用するプロセスについて説明します。This document outlines the process we use. プロセスは、計画するためのより優れた方法が見つかるたびに進化し続けますが、一般的な考え方は変わりません。The process is continually evolving as we find better ways to plan, but the general ideas remain the same.

さまざまな種類のリリースDifferent kinds of releases

リリースの種類によって、さまざまな種類の変更が含まれています。Different kinds of release contain different kinds of changes. これは、リリースの計画がリリースの種類によって異なることを意味します。This in turn means that the release planning is different for different kinds of release.

パッチ リリースPatch releases

パッチ リリースでは、バージョンの "パッチ" 部分のみが変更されます。Patch releases change only the "patch" part of the version. たとえば、EF Core 3.1.1 は、EF Core 3.1.0 で見つかった問題を修正するためのリリースです。For example, EF Core 3.1.1 is a release that patches issues found in EF Core 3.1.0.

パッチ リリースは、重大な顧客のバグを修正することを目的としています。Patch releases are intended to fix critical customer bugs. つまり、パッチ リリースには、新機能は含まれていません。This means patch releases do not include new features. 特別な状況を除き、パッチ リリースでは API の変更は許可されていません。API changes are not allowed in patch releases except in special circumstances.

パッチ リリースで変更を実施するためのハードルは非常に高くなっています。The bar to make a change in a patch release is very high. これは、パッチ リリースによって新しいバグを発生させないことが重要であるためです。This is because it is critical that patch releases do not introduce new bugs. そのため、決定プロセスにおいては、高価値および低リスクが重要視されます。Therefore, the decision process emphasizes high value and low risk.

次の場合、問題が修正される可能性が高くなります。We are more likely to patch an issue if:

  • 複数の顧客に影響があるIt is impacting multiple customers
  • 以前のリリースからの再発であるIt is a regression from a previous release
  • 問題が原因でデータが破損するThe failure causes data corruption

次の場合、問題が修正される可能性は低くなります。We are less likely to patch an issue if:

  • 適切な回避策があるThere are reasonable workarounds
  • 修正によって他の問題が発生する危険性が高いThe fix has high risk of breaking something else
  • バグが奥深い場所にあるThe bug is in a corner-case

このハードルは、長期サポート (LTS) リリースの有効期間において徐々に上がっていきます。This bar gradually rises through the lifetime of a long-term support (LTS) release. これは、LTS リリースでは安定性が重視されるためです。This is because LTS releases emphasize stability.

問題を修正するかどうかについての最終的な決定は、Microsoft の .NET ディレクターによって行われます。The final decision about whether or not to patch an issue is made by the .NET Directors at Microsoft.

マイナー リリースMinor releases

マイナー リリースでは、バージョンの "マイナー" 部分のみが変更されます。Minor releases change only the "minor" part of the version. たとえば、EF Core 3.1.0 は、EF Core 3.0.0 に対する改良を行うためのリリースです。For example, EF Core 3.1.0 is a release that improves on EF Core 3.0.0.

マイナー リリース:Minor releases:

  • 以前のリリースの品質と機能を改良することを目的としていますAre intended to improve the quality and features of the previous release
  • 通常、バグの修正と新機能が含まれていますTypically contain bug fixes and new features
  • 重大な変更は意図的には含まれませんDo not include intentional breaking changes
  • いくつかのプレリリース レビューが NuGet にプッシュされていますHave a few prerelease previews pushed to NuGet

メジャー リリースMajor releases

メジャー リリースでは、EF の "メジャー" バージョン番号が変更されます。Major releases change the EF "major" version number. たとえば、EF Core 3.0.0 は、EF Core 2.2.x を大きく前進させたメジャー リリースです。For example, EF Core 3.0.0 is a major release that makes a big step forward over EF Core 2.2.x.

メジャー リリース:Major releases:

  • 以前のリリースの品質と機能を改良することを目的としていますAre intended to improve the quality and features of the previous release
  • 通常、バグの修正と新機能が含まれていますTypically contain bug fixes and new features
    • EF Core の動作方法に対する根本的な変更となる新機能がある場合もありますSome of the new features may be fundamental changes to the way EF Core works
  • 通常、重大な変更が意図的に含まれていますTypically include intentional breaking changes
    • 重大な変更は、理解が進むとともに EF Core を進化させるために必要なものですBreaking changes are necessary part of evolving EF Core as we learn
    • ただし、顧客に影響を与える可能性があるため、重大な変更については慎重に検討を行います。However, we think very carefully about making any breaking change because of the potential customer impact. 過去には、重大な変更をかなり積極的に行った部分もあるかもしれません。We may have been too aggressive with breaking changes in the past. 今後は、アプリケーションを中断する変更を最小限に抑え、データベース プロバイダーや拡張機能を損なう変更を減らすことに努めています。Going forward, we will strive to minimize changes that break applications, and to reduce changes that break database providers and extensions.
  • 多くのプレリリース レビューが NuGet にプッシュされていますHave many prerelease previews pushed to NuGet

メジャーまたはマイナー リリースの計画Planning for major/minor releases

GitHub 問題追跡GitHub issue tracking

GitHub (https://github.com/dotnet/efcore) は、すべての EF Core 計画の信頼できる情報源です。GitHub (https://github.com/dotnet/efcore) is the source-of-truth for all EF Core planning.

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

  • 状態A state
    • Open は、未対応の問題です。Open issues have not been addressed.
    • Closed は、対応された問題です。Closed issues have been addressed.
      • 修正された問題にはすべて、closed-fixed のタグが付けられますAll issues that have been fixed are tagged with closed-fixed. closed-fixed のタグが付けられた問題は、修正されマージされていますが、リリースされていない場合があります。An issue tagged with closed-fixed is fixed and merged, but may not have been released.
      • その他の closed- ラベルは、問題を終了する他の理由を示すものです。Other closed- labels indicate other reasons for closing an issue. たとえば、重複するものには closed-duplicate というタグが付けられています。For example, duplicates are tagged with closed-duplicate.
  • 種類A type
    • Bugs は、バグを表します。Bugs represent bugs.
    • Enhancements は、新機能または既存の機能の改良された機能を表します。Enhancements represent new features or better functionality in existing features.
  • マイルストーンA milestone
  • 投票Votes!
    • 投票は、ある問題が自分にとって重要であるということを示す、最善の方法です。Voting is the best way to indicate that an issue is important to you.
    • 投票するには、その問題に対して "上向きの親指" 👍 を追加するだけです。To vote, just add a "thumbs-up" 👍 to the issue. たとえば、これらが投票数の多い問題ですFor example, these are the top-voted issues
    • また、そうすることで効果が生まれると思われる場合は、機能を必要とする具体的な理由についてコメントしてください。Please also comment describing specific reasons you need the feature if you feel this adds value. 「+ 1」などのコメントを付けても、効果は生まれません。Commenting "+1" or similar does not add value.

計画プロセスThe planning process

計画プロセスには、最もリクエストが多い機能をバックログから取得する以上のことが含まれます。The planning process is more involved than just taking the top-most requested features from the backlog. これは、複数の関係者からのフィードバックを複数の方法で収集するためです。This is because we gather feedback from multiple stakeholders in multiple ways. その後、次に基づいてリリースを形づくります。We then shape a release based on:

  • 顧客からのインプットInput from customers
  • 他の関係者からのインプットInput from other stakeholders
  • 戦略上の方向性Strategic direction
  • 利用可能なリソースResources available
  • スケジュールSchedule

次のような質問を検討します。Some of the questions we ask are:

  1. この機能を使用する開発者の数は? アプリケーション/エクスペリエンスをどの程度向上させますか?How many developers we think will use the feature and how much better will it make their applications or experience? この質問に答えるために、多くのソースからフィードバックを収集します。問題についてのコメントと投票は、これらのソースの 1 つです。To answer this question, we collect feedback from many sources — Comments and votes on issues is one of those sources. 重要な顧客との特定の契約は別のものです。Specific engagements with important customers is another.

  2. この機能をまだ実装していない場合、ユーザーが使用できる回避策とは?What are the workarounds people can use if we don't implement this feature yet? たとえば、多対多のネイティブ サポートがないことを回避するために、多くの開発者は統合テーブルをマップすることができます。For example, many developers can map a join table to work around lack of native many-to-many support. 当然ながら、すべての開発者がこれを実行するわけではありませんが、その多くは実行できます。そしてこれは決定の要因としてカウントされます。Obviously, not all developers want to do it, but many can, and that counts as a factor in our decision.

  3. 他の機能を実装させるようにするなど、この機能の実装によって EF Core のアーキテクチャは進化しますか?Does implementing this feature evolve the architecture of EF Core such that it moves us closer to implementing other features? 他の機能の構成要素として動作する機能は優先される傾向があります。We tend to favor features that act as building blocks for other features. たとえば、プロパティ バッグ エンティティによって多対多のサポートを進めることができ、エンティティ コンストラクターによって遅延読み込みのサポートが可能になりました。For instance, property bag entities can help us move towards many-to-many support, and entity constructors enabled our lazy loading support.

  4. この機能は拡張ポイントですか?Is the feature an extensibility point? 拡張ポイントは通常の機能よりも優先される傾向があります。なぜなら、開発者がこれらを使用して、それぞれの独自の動作をフックし、不足している機能を補うことができるためです。We tend to favor extensibility points over normal features because they enable developers to hook their own behaviors and compensate for any missing functionality.

  5. 他の製品と組み合わせて使用するときの機能のシナジーとは何ですか?What is the synergy of the feature when used in combination with other products? .NET Core、最新バージョンの Visual Studio、Microsoft Azure など、その他の製品と共に EF Core を使用するエクスペリエンスを可能にする、または大幅に向上させる機能は、優先される傾向があります。We favor features that enable or significantly improve the experience of using EF Core with other products, such as .NET Core, the latest version of Visual Studio, Microsoft Azure, and so on.

  6. 機能に取り組むために利用できるユーザーのスキルは何ですか? これらのリソースを最大限に活用する方法はありますか?What are the skills of the people available to work on a feature, and how can we best leverage these resources? EF チームの各メンバーおよびコミュニティの共同作成者は、異なる領域におけるさまざまなレベルの経験を持っているので、それに応じて計画を立てる必要があります。Each member of the EF team and our community contributors has different levels of experience in different areas, so we have to plan accordingly. GroupBy の変換や多対多など、特定の機能に取り組むために "全員の協力" が欲しくなる場合であっても、それは実用的ではありません。Even if we wanted to have "all hands on deck" to work on a specific feature like GroupBy translations, or many-to-many, that wouldn't be practical.