Proces planowania wersji
Często otrzymujemy pytania dotyczące sposobu wybierania określonych funkcji, aby przejść do określonej wersji. W tym dokumencie opisano używany proces. Proces ten stale ewoluuje, ponieważ znajdujemy lepsze sposoby planowania, ale ogólne pomysły pozostają takie same.
Różne rodzaje wydań
Różne rodzaje wydania zawierają różne rodzaje zmian. Oznacza to z kolei, że planowanie wydania różni się w przypadku różnych rodzajów wydań.
Wersje poprawek
Wersje poprawek zmieniają tylko część "patch" wersji. Na przykład EF Core 3.1.1 to wydanie, które dotyczy problemów z poprawkami znalezionymi w programie EF Core 3.1.0.
Wersje poprawek mają na celu naprawienie krytycznych usterek klienta. Oznacza to, że wersje poprawek nie zawierają nowych funkcji. Zmiany interfejsu API nie są dozwolone w wersjach poprawek, z wyjątkiem sytuacji specjalnych.
Pasek umożliwiający wprowadzenie zmiany w wydaniu poprawki jest bardzo wysoki. Jest to spowodowane tym, że ważne jest, aby wydania poprawek nie wprowadzały nowych usterek. W związku z tym proces decyzyjny podkreśla wysoką wartość i niskie ryzyko.
Istnieje większe prawdopodobieństwo, że wystąpi problem, jeśli:
- Ma to wpływ na wielu klientów
- Jest to regresja z poprzedniej wersji
- Awaria powoduje uszkodzenie danych
Mniej prawdopodobne jest, aby rozwiązać problem, jeśli:
- Istnieją rozsądne obejścia
- Poprawka ma duże ryzyko przerwania czegoś innego
- Usterka znajduje się w rogu
Ten pasek stopniowo wzrasta przez okres istnienia wersji długoterminowej pomocy technicznej (LTS ). Wynika to z faktu, że wydania LTS podkreślają stabilność.
Ostateczna decyzja o tym, czy zastosować poprawkę problemu, jest podjęta przez dyrektorów platformy .NET w firmie Microsoft.
Główne wersje
Główne wersje zmieniają numer wersji programu EF "wersja główna". Na przykład ef Core 3.0.0 jest głównym wydaniem, które sprawia, że duży krok naprzód w programie EF Core 2.2.x.
Główne wersje:
- Mają na celu poprawę jakości i funkcji poprzedniej wersji
- Zazwyczaj zawierają poprawki błędów i nowe funkcje
- Niektóre nowe funkcje mogą być podstawowymi zmianami sposobu działania platformy EF Core
- Zazwyczaj obejmują zamierzone zmiany powodujące niezgodność
- Istotne zmiany są niezbędne do rozwoju platformy EF Core w miarę nauki
- Uważamy jednak, że bardzo uważnie wprowadzamy wszelkie zmiany powodujące niezgodność ze względu na potencjalny wpływ na klienta. Być może byliśmy zbyt agresywni z powodu przełomowych zmian w przeszłości. W przyszłości będziemy dążyć do zminimalizowania zmian, które przerywają działanie aplikacji, oraz zmniejszenia zmian powodujących przerwanie dostawców baz danych i rozszerzeń.
- Wypchnięcie wielu wersji wstępnych do narzędzia NuGet
Planowanie wersji głównych/pomocniczych
Śledzenie problemów z usługą GitHub
GitHub (https://github.com/dotnet/efcore) to źródło prawdy dla całego planowania platformy EF Core.
Problemy w usłudze GitHub mają:
- Stan
- Otwarte problemy nie zostały rozwiązane.
- Rozwiązano zamknięte problemy.
- Wszystkie rozwiązane problemy zostały oznaczone jako zamknięte. Problem otagowany za pomocą zamkniętej poprawki został rozwiązany i scalony, ale mógł nie zostać wydany.
- Inne
closed-
etykiety wskazują inne przyczyny zamknięcia problemu. Na przykład duplikaty są oznaczane za pomocą zduplikowanych zamkniętych.
- Typ
- Usterki reprezentują usterki .
- Ulepszenia reprezentują nowe funkcje lub lepsze funkcje w istniejących funkcjach.
- Punkt kontrolny
- Problemy z brakiem kamienia milowego są brane pod uwagę przez zespół. Decyzja o tym, co zrobić z tą kwestią, nie została jeszcze podjęta lub rozważana jest zmiana decyzji.
- Problemy z punktem kontrolnym listy prac to elementy, nad którymi zespół EF rozważy pracę w przyszłej wersji
- Problemy z listą prac mogą być oznaczone tagiem "rozważ dla następnego wydania ", co oznacza, że ten element roboczy jest wysoki na liście dla następnej wersji.
- Otwarte problemy w wersji punktu kontrolnego to elementy, nad którymi zespół planuje pracować w tej wersji. Na przykład są to problemy, nad które planujemy pracować na platformie EF Core 5.0.
- Zamknięte problemy w wersji punktu kontrolnego to problemy, które zostały ukończone dla tej wersji. Należy pamiętać, że wersja mogła jeszcze nie zostać wydana. Na przykład są to problemy zakończone dla platformy EF Core 3.0.
- Głosów!
- Głosowanie jest najlepszym sposobem wskazywania, że problem jest dla Ciebie ważny.
- Aby głosować, wystarczy dodać "thumbs-up" 👍 do problemu. Na przykład są to najważniejsze problemy z głosowaniem
- Dodaj również komentarz opisujący konkretne przyczyny, dla których potrzebujesz funkcji, jeśli uważasz, że ta wartość dodaje wartość. Oznaczanie komentarza "+1" lub podobnego nie powoduje dodania wartości.
Proces planowania
Proces planowania jest bardziej zaangażowany niż tylko pobieranie najbardziej żądanych funkcji z listy prac. Dzieje się tak, ponieważ zbieramy opinie wielu uczestników projektu na wiele sposobów. Następnie kształtujemy wydanie na podstawie:
- Dane wejściowe od klientów
- Dane wejściowe od innych uczestników projektu
- Kierunek strategiczny
- Dostępne zasoby
- Zaplanuj
Oto niektóre pytania, które zadajemy:
Ilu deweloperów uważamy, że będzie korzystać z tej funkcji i ile lepiej sprawi, że ich aplikacje lub środowisko? Aby odpowiedzieć na to pytanie, zbieramy opinie z wielu źródeł — komentarze i głosy dotyczące problemów są jednym z tych źródeł. Konkretne zakontraktowanie z ważnymi klientami jest kolejnym.
Jakie obejścia mogą być używane przez użytkowników, jeśli jeszcze tej funkcji nie zaimplementowaliśmy? Na przykład wielu deweloperów może mapować tabelę sprzężenia, aby obejść brak natywnej obsługi wielu do wielu. Oczywiście nie wszyscy deweloperzy chcą to zrobić, ale wielu może i to liczy się jako czynnik w naszej decyzji.
Czy implementacja tej funkcji ewoluuje architekturę platformy EF Core, tak aby przybliżyła nas do implementowania innych funkcji? Mamy tendencję do faworyzowania funkcji, które działają jako bloki konstrukcyjne dla innych funkcji. Na przykład jednostki torby właściwości mogą pomóc nam przejść do obsługi wiele-do-wielu, a konstruktory jednostek umożliwiły obsługę ładowania leniwego.
Czy funkcja jest punktem rozszerzalności? Mamy tendencję do faworyzowania punktów rozszerzalności w normalnych funkcjach, ponieważ umożliwiają deweloperom podłączanie własnych zachowań i zrekompensowanie brakujących funkcji.
Jaka jest synergia funkcji w połączeniu z innymi produktami? Opowiadamy się za funkcjami, które umożliwiają lub znacznie ulepszają środowisko korzystania z platformy EF Core z innymi produktami, takimi jak .NET Core, najnowsza wersja programu Visual Studio, Microsoft Azure itd.
Jakie są umiejętności osób dostępnych do pracy nad funkcją i jak najlepiej wykorzystać te zasoby? Każdy członek zespołu EF i nasi współautorzy społeczności mają różne poziomy doświadczenia w różnych obszarach, więc musimy odpowiednio zaplanować. Nawet jeśli chcemy mieć "wszystkie ręce na pokład", aby pracować nad określoną funkcją, na przykład tłumaczenia GroupBy, lub wiele do wielu, to nie byłoby praktyczne.