5.3 KiB
Wersjonowanie Yii
Ten dokument podsumowuje politykę wersjonowania Yii. Naszą aktualną strategię wersjonowania można opisać jako ferver, którą uważamy za bardziej rozsądną i praktyczną niż wersjonowanie semantyczne (przejdź do #7408, aby zapoznać się z dyskusją).
Główni programiści Yii wiele razy już zgadzali się i podkreślali, że ważnym jest utrzymanie wydań 2.0.x w 100% kompatybilnych wstecznie. To jednak idealna teoria, a praktyka, opisana choćby w artykule o ferver na prawdziwym przykładzie, pokazuje, że ciężko jest to osiągnąć, niezależnie od tego czy używa się semver czy też nie.
Podsumowując, nasza polityka wersjonowania Yii 2 przedstawia się następująco:
Numery wersji
Numery wersji dodawane są w formacie 2.x.y.z
, gdzie z
można pominąć, w przypadku, gdy wynosi 0
.
Ewentualna wersja 3 Yii nie jest tu uwzględniania, ponieważ zakładamy, że skok rozwojowy będzie tutaj podobny jak w przypadku 2.0 zastępującego 1.0. Zakładamy, że przejście nastąpi co 3 do 5 lat, w zależności od rozwoju zewnętrznych technologii (takich jak aktualizacja PHP z 5.0 do 5.4).
2.X.0
: główne wydania
Wydania nie zachowujące wstecznej kompatybilności, które zawierają główne funkcjonalności i zmiany. Aktualizacja z wcześniejszych wersji może nie być trywialna, ale dostępna będzie zawsze dotycząca tego instrukcja.
- Zawiera głównie nowe funkcjonalności i poprawki błędów.
- Zawiera pomniejsze funkcjonalności i poprawki błędów z wydań łatających.
- Może zawierać zmiany nie zachowujące wstecznej kompatybilności, które są wymienione w pliku
UPGRADE-2.X.md
. - Cykl wydania to około 12 miesięcy lub więcej.
- Wymaga wydań poprzedzających:
2.X.0-alpha
,2.X.0-beta
,2.X.0-rc
. - Wymaga podania informacji o ważnym wydaniu i zabiegów marketingowych.
2.x.Y
: pomniejsze wydania
Wydania łatająces, które powinny być w 100% wstecznie kompatybilne. Zakładając idealny przypadek, mamy nadzieję, że zawierają tylko
zmiany nie wpływające na wsteczną kompatybilność, jednak ponieważ nie jest to zawsze możliwe, nota aktualizacyjna jest dodawana
w UPGRADE.md
. W praktyce, ponieważ 2.0.x są wydawane częściej, dodajemy tam pomniejsze funkcjonalności, aby użytkownicy mogli
nacieszyć się nimi wcześniej.
- Głównie zawierają poprawki błędów i pomniejsze ulepszenia funkcjonalności.
- Brak głównych zmian w funkcjonalnościach.
- Powinny być w 100% wstecznie kompatybilne, aby zapewnić bezproblemową aktualizację. Dozwolone jest tylko kilka wyjątków, które powinny być opisane w
UPGRADE.md
. - Cykl wydania to około 1 do 2 miesięcy.
- Nie wymagają wydań poprzedzających (alpha, beta, RC).
- Powinny być ciągle scalane z główną gałęzią projektu (ręcznie przynajmniej raz w tygodniu).
- Z ogłoszeniem o wydaniu. Strona projektu będzie również uaktualniona.
2.x.y.Z
: wydania łatające
Wydania łatające, które powinny być w 100% wstecznie kompatybilne, zawierające tylko poprawki błędów. Bez ogłoszeń o wydaniu lub aktualizacji strony projektu (chyba, że zawierają ważną poprawkę lub dotyczą bezpieczeństwa). Proces wydania odbędzie się głównie automatycznie.
- Zawierają tylko poprawki błędów, bez dodawania funkcjonalności.
- Muszą być w 100% wstecznie kompatybilne, aby zapewnić bezproblemową aktualizację. Dozwolone są tylko wyjątki w kwestii poprawy bezpieczeństwa, które mogą wymagać naruszenia wstecznej kompatybilności.
- Cykl produkcyjny to 1 do 2 tygodni.
- Nie wymagają wydań poprzedzających (alpha, beta, RC).
- Powinny być scalone z główną gałęzią projektu w momencie wydania.
Polityka dotycząca gałęzi projektu
- Gałąź
master
jest gałęzią deweloperską dla aktualnego stabilnego głównego wydania. - Praca nad każdym nowym głównym wydaniem będzie odbywać się w gałęzi nazwanej numerem wersji, np.
2.1
. - Kiedy główne wydanie
2.n
jest gotowe, należy utworzyć gałąź utrzymującą o nazwie2.(n-1).x
zmaster
. Przykładowo gałąź2.0
jest tworzona w momencie wydania stabilnej wersji2.1.0
, która to od tej pory będzie rozwijana wmaster
(zobacz schemat nazw gałęzi dla composera). - Tworzone są tagi
2.x.y.z
i2.x.y
gałęzi, aby oznaczyć wydania łat. Dla wydań2.x.y.0
pominięte będzie0
. - Zmiany w gałęzi utrzymującej
2.n.x
będą ciągle scalane domaster
.
Poniższy obrazek ilustruje historię gałęzi zmieniających się w czasie:
Wydania
Zarówno framework Yii 2, jak i oficjalne projekty rozszerzeń, przestrzegają powyższej polityki wersjonowania i gałęzi projektu. Framework i oficjalne rozszerzenia są wydawane niezależnie od siebie, zatem różnica numerów wersji pomiędzy tymi projektami jest czymś normalnym. Szablony projektów aplikacji są zawsze wydawane razem z frameworkiem.
Cykl wydawniczy opisany powyżej dotyczy tylko głównego frameworka. Rozszerzenia są wydawane w razie potrzeby. Rozszerzenie może nie otrzymywać nowych wydań przez bardzo długi czas, kiedy nie ma dla niego żadnych poprawek błędów lub ulepszeń.