Proces plánování vydaných verzí

Často dostáváme otázky týkající se toho, jak zvolit konkrétní funkce, které mají být součástí konkrétní verze. Tento dokument popisuje proces, který používáme. Proces se neustále vyvíjí, protože najdeme lepší způsoby plánování, ale obecné myšlenky zůstávají stejné.

Různé druhy verzí

Různé druhy verzí obsahují různé druhy změn. To zase znamená, že plánování vydávání verzí se liší pro různé druhy vydání.

Vydání oprav

Verze oprav mění pouze část verze "patch". Například EF Core 3.1.1 je verze, která opravuje problémy zjištěné v EF Core 3.1.0.

Verze oprav jsou určené k opravě kritických chyb zákazníků. To znamená, že verze oprav nezahrnují nové funkce. Změny rozhraní API nejsou povoleny ve verzích oprav s výjimkou zvláštních okolností.

Panel pro provedení změny ve vydané verzi opravy je velmi vysoký. Je to proto, že je důležité, aby verze oprav nezavádějí nové chyby. Proto rozhodovací proces zdůrazňuje vysokou hodnotu a nízké riziko.

S větší pravděpodobností opravíme problém, pokud:

• Má vliv na více zákazníků.
• Jedná se o regresi z předchozí verze.
• Selhání způsobuje poškození dat.

Méně pravděpodobné je, že problém opravíme, pokud:

• Existují rozumná alternativní řešení
• Oprava má vysoké riziko narušení něčeho jiného.
• Chyba je v rohu případu.

Tento pruh se postupně zvyšuje po celou dobu životnosti dlouhodobé verze podpory (LTS). Je to proto, že verze LTS zvýrazňují stabilitu.

Konečné rozhodnutí o tom, jestli se má problém opravit, provádí ředitelé .NET v Microsoftu.

Hlavní verze

Hlavní verze mění číslo hlavní verze EF. Například EF Core 3.0.0 je hlavní verze, která představuje velký krok vpřed oproti EF Core 2.2.x.

Hlavní verze:

• Cílem je zlepšit kvalitu a funkce předchozí verze.
• Obvykle obsahují opravy chyb a nové funkce.
  • Některé nové funkce můžou být zásadními změnami způsobu fungování EF Core.
• Obvykle zahrnují záměrné zásadní změny.
  • Zásadní změny jsou nezbytnou součástí vývoje EF Core, jak se učíme
  • Vzhledem k potenciálnímu dopadu zákazníků si ale velmi pečlivě myslíme, že provedeme jakoukoli zásadní změnu. Možná jsme byli příliš agresivní s zásadními změnami v minulosti. V budoucnu se budeme snažit minimalizovat změny, které přerušují aplikace, a omezit změny, které přerušují poskytovatele databází a rozšíření.
• Máte mnoho předběžných verzí Preview nabízených do NuGetu.

Plánování hlavních/dílčích verzí

Sledování problémů s GitHubem

GitHub (https://github.com/dotnet/efcore) je zdrojem pravdy pro veškeré plánování EF Core.

Problémy na GitHubu:

• Stav
  • Otevřené problémy nebyly vyřešeny.
  • Uzavřené problémy byly vyřešeny.
    • Všechny opravené problémy jsou označené uzavřenými opravami. Byl opraven problém označený jako uzavřený a sloučený, ale pravděpodobně nebyl vydán.
    • Jiné closed- popisky označují jiné důvody pro zavření problému. Například duplicity jsou označené uzavřenou duplicitou.
• Typ
  • Chyby představují chyby.
  • Vylepšení představují nové funkce nebo lepší funkce v existujících funkcích.
• Milník
  • Tým zvažuje problémy bez milníků . Rozhodnutí o tom, co s problémem dělat, ještě nebylo provedeno nebo se zvažuje změna rozhodnutí.
  • Problémy v milníku backlogu jsou položky, na které bude tým EF uvažovat v budoucí verzi.
    • Problémy v backlogu můžou být označené příznakem zvážení pro příští verzi , což znamená, že tato pracovní položka je v seznamu příští verze vysoká.
  • Otevřené problémy v milníku s verzí jsou položky, na které tým plánuje pracovat v této verzi. Jedná se například o problémy, na které plánujeme pracovat pro EF Core 5.0.
  • Uzavřené problémy v milníku s verzí jsou problémy, které se pro danou verzi dokončily. Mějte na paměti, že verze ještě nebyla vydána. Jedná se například o problémy dokončené pro EF Core 3.0.
• Hlasů!
  • Hlasování je nejlepší způsob, jak indikovat, že je pro vás problém důležitý.
  • Pokud chcete hlasovat, stačí k problému přidat "palec nahoru" 👍 . Jedná se například o nejčastější problémy s hlasováním.
  • Uveďte také popis konkrétních důvodů, proč funkci potřebujete, pokud si myslíte, že tato hodnota je přidaná. Komentář +1 nebo podobný nepřidává hodnotu.

Proces plánování

Proces plánování je více zapojený, než jen převzetí nejžádanějších funkcí z backlogu. Je to proto, že shromáždíme zpětnou vazbu od více zúčastněných stran několika způsoby. Potom vytvoříme verzi na základě:

• Vstup od zákazníků
• Vstup od ostatních zúčastněných stran
• Strategický směr
• Dostupné prostředky
• Plán

Mezi otázky, které klademe, patří:

1. Kolik vývojářů si myslíme, že tuto funkci budou používat a jak mnohem lépe zajistí jejich aplikace nebo prostředí? Abychom na tuto otázku odpověděli, shromažďujeme zpětnou vazbu z mnoha zdrojů – Komentáře a hlasy o problémech jsou jedním z těchto zdrojů. Konkrétní zapojení s důležitými zákazníky je další.

2. Jaká jsou alternativní řešení, která můžou uživatelé použít, pokud tuto funkci ještě neimplementujeme? Mnoho vývojářů může například namapovat tabulku spojení tak, aby fungovala s nedostatkem nativní podpory M:N. Samozřejmě, ne všichni vývojáři to chtějí, ale mnoho může, a to se počítá jako faktor v našem rozhodnutí.

3. Vyvíjí implementace této funkce architekturu EF Core tak, aby nás blíž k implementaci dalších funkcí? Upřednostňujeme funkce, které fungují jako stavební bloky pro jiné funkce. Entity kontejneru vlastností nám například můžou pomoct přejít k podpoře M:N a konstruktory entit povolily naši opožděnou podporu načítání.

4. Je tato funkce bodem rozšiřitelnosti? Upřednostňujeme body rozšiřitelnosti oproti běžným funkcím, protože vývojářům umožňují zahozovat vlastní chování a kompenzovat případné chybějící funkce.

5. Jaká je součinnost funkce při použití v kombinaci s jinými produkty? Upřednostňujeme funkce, které umožňují nebo výrazně vylepšují prostředí EF Core s jinými produkty, jako je .NET Core, nejnovější verze sady Visual Studio, Microsoft Azure atd.

6. Jaké jsou dovednosti lidí, kteří jsou k dispozici pro práci na funkci, a jak můžeme tyto prostředky nejlépe využít? Každý člen týmu EF a přispěvatelé naší komunity mají různé úrovně zkušeností v různých oblastech, takže musíme odpovídajícím způsobem plánovat. I když bychom chtěli mít "všechny ruce na palubě", aby fungovaly na konkrétní funkci, jako jsou překlady GroupBy nebo M:N, to by nebylo praktické.