發行計劃程序

在我們收到的問題中，經常有人問起我們如何決定將某功能加入特定的版本。 本檔概述我們使用的程式。 這個過程不斷演變，因為我們找到更好的計畫方式，但一般的想法保持不變。

不同類型的版本

不同類型的發行包含不同類型的變更。 這反過來又表示不同發行類型的發行規劃不同。

修補程式版本

修補程式版本只會變更版本的「修補程式」部分。 例如，EF Core 3.1。 1 是 EF Core 3.1 中發現修補程式問題的版本。 0 .

修補程式版本旨在修正重要的客戶錯誤。 這表示修補程式版本不包含新功能。 除了特殊情況外，修補程式版本不允許 API 變更。

在修補程式版本中進行變更的列很高。 這是因為修補程式版本不會引入新的 Bug 非常重要。 因此，決策程式強調高價值和低風險。

如果下列問題，我們更有可能修補問題：

• 它會影響多個客戶
• 這是舊版的回歸
• 失敗會導致資料損毀

如果下列問題，我們不太可能修補問題：

• 有合理的因應措施
• 修正程式有高風險中斷其他專案
• Bug 位於角落案例中

這個長條在長期支援 （LTS） 發行的 存留期內逐漸上升。 這是因為 LTS 版本強調穩定性。

關於是否要修補問題的最終決定是由 Microsoft 的 .NET Director 所做出。

主要版本

主要版本會變更 EF「主要」版本號碼。 例如，EF Core 3.0.0 是一個主要版本，在 EF Core 2.2.x 上向前邁出重要一步。

主要版本：

• 旨在改善上一版的品質和功能
• 通常包含 Bug 修正和新功能
  • 某些新功能可能是 EF Core 運作方式的基本變更
• 通常包含刻意的重大變更
  • 重大變更是不斷演進 EF Core 的必要部分，因為我們瞭解
  • 不過，由於潛在的客戶影響，我們非常仔細地考慮進行任何重大變更。 過去，我們可能對重大變化過於咄咄逼人。 接下來，我們將努力將中斷應用程式的變更降到最低，並減少中斷資料庫提供者和延伸模組的變更。
• 將許多發行前版本預覽推送至 NuGet

規劃主要/次要版本

GitHub 問題追蹤

GitHub （ https://github.com/dotnet/efcore ） 是所有 EF Core 規劃的真相來源。

GitHub 上的問題有：

• 狀態
  • 尚未解決開啟 的問題。
  • 已解決已關閉 的問題。
    • 所有已修正的問題都會 以已關閉的修正 標記。 已修正併合並標記為已關閉的問題，但可能尚未發行。
    • 其他 closed- 標籤表示關閉問題的其他原因。 例如，重複專案會以封閉式重複標記。
• 型別
  • Bug 代表 Bug。
  • 增強 功能代表現有功能中的新功能或更好的功能。
• 里程碑
  • 小組正在考慮沒有里程碑 的問題。 尚未就此問題採取什麼措施的決定，或正在審議該決定的改變。
  • 待辦專案里程碑 中的問題是 EF 小組在未來版本中將考慮處理的專案
    • 待辦專案的問題可能會 以考慮下一個版本 標記，指出下一個版本的清單上此工作專案很高。
  • 在版本設定里程碑中開啟的問題，是小組計畫在該版本中處理的專案。 例如， 以下是我們計畫針對 EF Core 5.0 處理的問題。
  • 版本設定里程碑中已關閉的問題是該版本已完成的問題。 請注意，版本可能尚未發行。 例如， 這些是 EF Core 3.0 已完成的問題。
• 票！
  • 投票是指出問題對你很重要的最佳方式。
  • 若要投票，只要將「拇指」 👍 新增至問題即可。 例如， 這些是投票率最高的問題
  • 如果您覺得此功能會增加價值，請加上批註，說明您需要此功能的特定原因。 批註 「+1」 或類似專案不會增加值。

規劃程式

規劃程式比只從待辦專案取得最要求的功能更涉及。 這是因為我們透過多種方式收集來自多個專案關係人的意見反應。 然後，我們會根據：

• 來自客戶的輸入
• 來自其他專案關係人的意見
• 策略性方向
• 可用的資源
• 排程

我們詢問的一些問題如下：

1. 我們認為多少開發人員會使用此功能，而它讓他們的應用程式或體驗改善多少？ 為了回答這個問題，我們從許多來源收集意見反應 — 問題的留言與投票是那些來源之一。 與重要客戶的特定參與是另一個。

2. 如果我們尚未實作這項功能，那有哪些因應措施可用？ 舉例來說，許多開發人員在缺少原生多對多支援時，都會想到運用聯合資料表作為因應措施。 很明顯地，並非所有開發人員都想這麼做，但其中許多人都做得到，而這也是我們決策中所考量的因素。

3. 實作此功能是否會涉及 EF Core 的架構，使我們更加需要實作其他功能？ 我們偏好可作為其他功能建置組塊的功能。 比方說，屬性包實體可以協助我們邁向多對多的支援，而實體建構函式則促成了消極式載入支援。

4. 這項功能是擴充點嗎？ 因為擴充點使開發人員能夠輕鬆地依自己的習慣使用，並填補任何功能上的缺失，所以我們偏好擴充點勝過於一般功能。

5. 此功能與其他產品搭配使用時的綜效如何？ 我們偏好能促成或大幅改善 EF Core 搭配其他產品使用體驗的功能，例如 .NET Core、最新版本的 Visual Studio、Microsoft Azure 等等。

6. 哪些人員可以使用哪些技能來處理功能，以及如何充分利用這些資源？ 每位 EF 小組的成員及我們社群的參與者，在不同領域都各有不同程度的經驗，所以我們必須據此進行規劃。 即使我們希望將「所有人力」集中在像是 GroupBy 翻譯，或多對多關聯性等特定功能上，也無法實際付諸行動。