diff --git a/docs/internals-pl/exception_hierarchy.png b/docs/internals-pl/exception_hierarchy.png
new file mode 100644
index 0000000000..2c43e03793
Binary files /dev/null and b/docs/internals-pl/exception_hierarchy.png differ
diff --git a/docs/internals-pl/exception_hierarchy.vsd b/docs/internals-pl/exception_hierarchy.vsd
new file mode 100644
index 0000000000..d044ea9315
Binary files /dev/null and b/docs/internals-pl/exception_hierarchy.vsd differ
diff --git a/docs/internals-pl/schema-builder-patterns.xlsx b/docs/internals-pl/schema-builder-patterns.xlsx
new file mode 100644
index 0000000000..32bf142e59
Binary files /dev/null and b/docs/internals-pl/schema-builder-patterns.xlsx differ
diff --git a/docs/internals-pl/versions-branches.png b/docs/internals-pl/versions-branches.png
new file mode 100644
index 0000000000..5192c1d191
Binary files /dev/null and b/docs/internals-pl/versions-branches.png differ
diff --git a/docs/internals-pl/versions.md b/docs/internals-pl/versions.md
new file mode 100644
index 0000000000..a29b7263f8
--- /dev/null
+++ b/docs/internals-pl/versions.md
@@ -0,0 +1,88 @@
+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:
+
+![Polityka gałęzi projektu](versions-branches.png)
+
+
+## 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ń.