Cacher is the code snippet organizer for pro developers

Najważniejsze informacje

• do oznaczenia wersji używamy trzech liczb oddzielonych kropką: 3.2.11
• major release - pierwsza cyfra - podbijamy, gdy tworzymy duże wydanie serwisu lub biblioteki, które bazuje na istniejącym kodzie (w praktyce może to być np. nowa wersja serwisu, w której zmienił się cały front, a back-end pozostał bez zmian)
• feature release - drugą cyfra - podbijamy, gdy rozszerzamy funkcjonalność serwisu lub biblioteki
• hotfix release - trzecią cyfra - podbijamy, gdy wprowadzamy małe poprawki lub naprawiamy błędy w istniejącej funkcjonalności
• nie używamy prefiksa v, np. źle: v3.2.11, dobrze: 3.2.11

TL;DR

Przyjmuje się że podając wersję oprogramowania używamy trzech liczb oddzielonych kropką. Przykładowo:

3.2.11

Oznaczają one kolejno:

• major release (3) - pierwsza cyfra oznacza główne wydanie biblioteki. Oznacza że zmiany zaszły tak daleko że nowy kod nie będzie działał ze starszymi rozwiązaniami. Tzn kod nie jest wstecznie kompatybilny za sprawą zmiany struktury, nazw czy interfejsu. Dla przykładu powiedzmy że masz kod w wersji 1.0.0. Wprowadziłeś jakieś zmiany które sprawiają że programy które go używają przestaną działać. W tym momencie poprawki w kodzie powinieneś wypuścić jako wersja 2.0.0. Uwaga, wersja 1.0.0 to tzw stable release. Oznacza to że nasz kod osiągnął wersję która działa i ma się dobrze. I w której nie zajdą już jakieś poważne zmiany. W momencie kiedy kod jest nadal w wersji 0.x.x, mogą w nim zajść dowolne zmiany zrywające nawet wsteczną kompatybilność i nadal nie oznacza to że musimy podbić pierwszą cyfrę (major release). Powyższą konwencję stosujemy dopiero wtedy kiedy nasz kod osiągnie minimum wersję 1.0.0.
• feature release (2) - druga cyfra oznacza zmiany nie zrywające z wsteczną kompatybilnością. Co oznacza że po aktualizacji programy które używają nasz kod powinny dalej działać jak dotychczas. Nazwa feature release została użyta dlatego że na ogół zmieniamy tą cyfrę gdy dodajemy jakieś nowości do biblioteki które nie wpływają na jej działanie a rozszerzają ją. Dla przykładu mamy bibliotekę w wersji 2.0.0. Dodajemy jej nowe metody które mają realizować nowe zadania. Lub zmieniamy obecne metody tak że nie wpływa to na ich dotychczasowe używanie. Wtedy wypuszczamy taki kod jako wersję 2.1.0.
• hotfix release (11) - trzecia cyfra oznacza poprawki w kodzie. W momencie gdy dokonamy optymalizacji na naszym kodzie lub naprawimy znaleziony błąd, podbijamy trzecią cyfrę w wersji naszego kodu. Powiedzmy że mamy bibliotekę w wersji 2.1.0. Znaleźliśmy błąd. Biblioteka w którymś momencie źle dodawała liczby. Naprawiamy ów błąd co nie zmieniło w zasadzie sposobu używania biblioteki czy samego jej interfejsu. W tym momencie wydajemy kod w wersji 2.1.1. Należy pamiętać że jeżeli wprowadzamy szersze zmiany w kodzie, zawsze należy się zastanowić czy nie jest ich tak dużo że należy już wypuścić np wersję 2.2.0. Ale na ogół robi się to tylko przy szerokich zmianach który w jakiś sposób modyfikują używanie biblioteki. Chociażby poprzez rozszerzenie jej o nowe możliwości. Przyjmuje się następujące dopuszczalne sposoby zapisu:

3.2.11
3.2.11
3.2.21-alpha
3.2.15-dev
3.2.12-beta2
3.2.12-RC5