You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
89 lines
5.3 KiB
89 lines
5.3 KiB
8 years ago
|
Wersjonowanie Yii
|
||
|
|
=================
|
||
|
|
|
||
|
|
Ten dokument podsumowuje politykę wersjonowania Yii. Naszą aktualną strategię wersjonowania można opisać jako
|
||
|
|
[ferver](https://github.com/jonathanong/ferver), którą uważamy za bardziej rozsądną i praktyczną niż
|
||
|
|
[wersjonowanie semantyczne](http://semver.org/) (przejdź do [#7408](https://github.com/yiisoft/yii2/issues/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 nazwie `2.(n-1).x` z `master`.
|
||
|
|
Przykładowo gałąź `2.0` jest tworzona w momencie wydania stabilnej wersji `2.1.0`, która to od tej pory będzie rozwijana w `master`
|
||
|
|
(zobacz [schemat nazw gałęzi dla composera](https://getcomposer.org/doc/02-libraries.md#branches)).
|
||
|
|
* Tworzone są tagi `2.x.y.z` i `2.x.y` gałęzi, aby oznaczyć wydania łat. Dla wydań `2.x.y.0` pominięte będzie `0`.
|
||
|
|
* Zmiany w gałęzi utrzymującej `2.n.x` będą ciągle scalane do `master`.
|
||
|
|
|
||
|
|
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ń.
|