Baza wiedzy

Artykuł pochodzi ze strony http://wortal.php.pl/wortal/artykuly/pomysly_porady_sugestie_dobre_nawyki/wersjonowanie_aplikacji

Wielu z nas pisząc aplikacje używa własnych sposobów nadawania numerów wersji aplikacji/dokumentów. I mimo, że większość jest podobna do siebie to jednak mogą być inaczej interpretowane przez różne osoby. Dlatego przedstawię tutaj wypracowany przeze mnie schemat wersjonowania aplikacji, co pozwoli na pewne ustandaryzowanie nadawania numerów wersjom.

Zacznijmy od dwóch podstawowych elementów w wersjonowaniu:

1. Numer wersji
2. Kategoria wersji

Numer wersji to nic innego jak ciąg cyfr i kropek określający wersje, a kategoria to dodatkowy atrybut nadawany wersjom, które mają specyficzne przeznaczenie.

Schemat wersji wygląda tak:

<numer wersji>-<kategoria wersji>>

Przyjrzyjmy się teraz dokładniej poszczególnym elementom.
Numer wersji

Numer wersji posiada swój specyficzny „pod schemat”, który wygląda następująco:

<major>.<minor>.<path/build>

Gdzie major, minor i path/build to znaki liczbowe. Ostatni element (path/build) może być pominięty, jeżeli wynosi 0 (zero).

Major

Numer ten charakteryzuje nam wersje, która w porównaniu do poprzedniej posiada znaczące zmiany, nieograniczające się tylko do kosmetyki, ale do ważnych aspektów działania aplikacji. Może to być np. nowy sposób komunikacji się aplikacji z klientem, nowy rodzaj wymiany danych czy zupełnie inny sposób działania całego systemu.

Minor

Numer określający wprowadzenie nowych elementów do aplikacji nie wpływających w znaczącym stopniu na zmiany w strukturze całej aplikacji. Może to być np. dodanie nowych przycisków czy innych elementów, które na drodze np. kontaktu z klientem doprowadziły do zmian w celu podniesienia funkcjonalności aplikacji.

Path/build

Jest to numer określający wprowadzenie poprawki naprawiającej wykryty błąd/błędy albo numer kompilacji programu (inkrementowany przez kompilator).
Kategoria

Aby nadać dodatkowy atrybut wersjom używa się specyficznych kategorii:

Develope

Skrót: dev lub d

Kategoria dla aplikacji, które są w fazie rozwojowej. Dostępne dla określonej grupy ludzi (przeważnie developerów lub zaufanych członków zespołu).

Alpha

Skrót: alpha lub a

Kategoria dla aplikacji, która przeszła „głosowanie” – została zaakceptowana przez grupę developerów do dalszych testów przez nich samych.

Beta

Skrót: beta lub b

Kategoria przeznaczona dla szerszej grupy testerów – członków pracujących nad projektem zajmujących się głównie testowaniem aplikacji.

Relase Candidate / Relase

Skróty: rc lub r

Kategoria aplikacji przeznaczona dla wszystkich zainteresowanych osób. Posiadająca najmniej błędów – w porównaniu do powyższych kategorii. Jest to częściowo skończony projekt, z większością możliwości, jakie będzie posiadał finalny produkt. Przeważnie aplikacja taka jest po to, aby poprawić elementy, które użytkownik końcowy uzna za źle rozwiązane (np. nawigacja w programie, kolory itp. itd.) oraz błędy, które wcześniej nie zostały wykryte.

Final

Skrót final lub f

Ostateczna wersja trafiająca do klienta. Przeważnie nie dodaje się tej kategorii do wersji i jest ona „umówna”.

Trzeba zaznaczyć, że do kategorii można dodać także dodatkowy numer np. RC 1, RC 2. Określający kolejny „pod etap” w wersjonowaniu aplikacji. Im wyższy numer tym „szybciej” do następnej kategorii (nie ma maksymalnej granicy w nadawaniu dodatkowych numerów, jednak nie powinny one przekraczać cyfry 5)
Przykłady

* 1.0 – Pierwsza finalna wersja
* 0.1-dev – Aplikacja w fazie rozwojowej, która nie posiada jeszcze wszystkich elementów „pełnej” wersji
* 2.2.34 – Finalna aplikacja zawierająca pewne poprawki w stosunku do wersji 2.0 oraz załatane dziury
* 1.0-RC – Pierwsza wersja aplikacji przeznaczona do testowania przez osoby z zewnątrz