v X.X.X numery wersji, oto jak działają
Skąd się biorą numery wersji?
- Angular 4.0.0
- jQuery 3.2.1
- Laravel 5.4.WordPress
- WordPress 4.8.2
Zastanawiałeś się kiedyś, dlaczego numery wersji wyglądają akurat tak, a nie inaczej? Dlaczego składają się akurat z trzech liczb, a nie z dwóch albo czterech? Kiedy następuje zwiększenie każdej kolejnej? Jak ty podpisujesz swoje pliki?
Jeżeli do tej pory nie wiedziałeś, że numery wersji mają jakiś większy sens, zatrzymaj się tutaj… Pomyśl jak robiłeś to ty? Jakiej logiki używałeś? Być może za chwile okaże się, że robiłeś to we właściwy sposób… to by oznaczało, że wpadłeś na naprawdę świetny pomysł!
BTW. Ja kiedyś nazywałem pliki wg własnej logiki, jeśli wydawało mi się, że mój CMS jest lepszy to zwiększałem, którąś z cyferek… nieważne którą… szkoda, że sam nie trafiłem wcześniej na taki post.
Okazuje się, że jest w tym wszystkim jest większy sens, że z samego numeru wersji można wywnioskować znacznie więcej niż się wydaje.
Po co mi to?
Za chwilę zobaczysz, że patrząc jedynie na numer wersji będziesz wiedział, czy plik będzie kompatybilny z resztą. Patrząc na numer wersji, będziesz wiedział, czy możesz bez strachu włączyć aktualizacje WordPressa. Patrząc na numer wersji będziesz wiedział jak dużych i groźnych zmian możesz się spodziewać.
Brzmi zadowalająco? Jeśli tak to lećmy dalej. To całe numerowanie ma swoją nazwę…
Semantyczne wersjonowanie
Bo tak to się właśnie nazywa (skrót: SemVer). Jak już pewnie wiesz, semantyka to coś, co nadaje danej rzeczy logiczny sens, jakieś zadanie. Przypisuje znaczenie. W przypadku semantycznego wwersjonowania, chodzi o to, że liczby w numerze wersji nie są losowym ciągiem cyfr, ale są stworzone wg konkretnych zasad.
W skrócie
Jeśli jednak chcesz przeczytać streszczenie, oto one:
Wersja nr: X.Y.Z
X – MAJOR, jest to poważna zmiana wersji. Jest to zmiana, która nie jest kompatybilna wstecz. Update
Y – MINOR, jest to mniejsza poprawka – dodanie nowej funkcjonalności, która musi być kompatybilna z poprzednimi wersjami.. Jednak developerzy Angulara (czyt. Google), stosuje ją jako poprawkę, która może wymagać drobnej ingerencji programisty. Czyli jak to mówił któryś z ich pracowników na konferencji: wszystko będzie działać, ale być może będziesz musiał wprowadzić kilka poprawek, może tylko zmienić gdzieś nazwę, ale prawdopodobnie nic…
Z – PATCH, jest to zazwyczaj jakaś naprawa błędu, która jest kompatybilna z poprzednimi wersjami. Jeśli to właśnie ta liczba się zmienia, możesz bez strachu robić update.
Poza camymi cyframi możemy używać jeszcze „rozszerzeń” naszych nazw, np. „-beta”, który informuje, że jest to wersja …beta, alpha, rc, itd.
Jakakolwiek zmiana w kodzie musi być wypuszczona wraz z nowym numerem. Nie możemy wypuścić wersji 2.3.1, a później dorzucić kawałek kodu, bo „zapomniałem dopisać jednej zmiennej”. Każda zmiana w kodzie, która jest udostępniana to kolejny numer wersji.
Kiedy stosować semantyczne wersjonowanie
Żeby pełnoprawnie powiedzieć, że używamy semantycznego wersjonowania nasz kod musi mieć publicze API. Ponieważ SemVer służy nie tyle tobie, ile użytkownikom korzystającym z twojego kodu. Po to, aby ONI wiedzieli czego mogą się spodziewać.
Nie widzę jednak przeszkód, żeby trzymać się tych samym zasad nawet podczas nazywania swoich małych, prywatnych skrypcików.
Od jakiego numeru zacząć
Każdy projekt można podzielić na 2 fazy: fazę rozwoju (gdy tworzymy kod i w każdej chwili coś może się zmienić) oraz fazę, gdy kod jest już publicznie udostępniony do użytku (czyli już mamy gotową podstawę, którą rozwijamy).
- Faza rozwoju rozpoczyna się od zera: 0.1.0
- Gdy kod jest gotowy i wypuszczamy go oficjalnie do użytku, pierwszą wersją będzie numer: 1.0.0
Całkiem proste, nie? Jeśli chcesz się dokładnie zagłębić w dłuższy opis i zasady rządzące tym tworem (do czego zachęcam), odsyłam tutaj (na końcu strony jest nawet FAQ).: