Numeracja wersji oprogramowania Open Source

W związku z pewnym nieporozumieniem, pomyślałem sobie, że warto byłoby przybliżyć/przypomnieć najczęściej używaną dziś konwencję numeracji wersji oprogramowania.

Programy FOSS są zawsze w stanie rozwoju, więc nie mają numerów kolejnych wydań przez producenta, roku wydania konkretnej paczki, czy innego symbolu. Są oznaczane numerami kolejnej, w miarę ustabilizowanej wersji, która nadaje się do użytku, o zamkniętej w miarę funkcjonalności. Numery te dają również pojęcie z której linii rozwoju i którego momentu czasu rozwoju, pochodzi dana wersja programu.

Numer wersji programu jest zestawieniem kilku liczb naturalnych: Major (główna), Minor (dodatkowa), Release (wydania) i czasami jeszcze Build (w przypadku tzw. nightly-build). Poszczególne składniki są kolejno inkrementowane podczas zmiany. Często projekty nie używają wszystkich składników, albo nazywają je inaczej (np. Linux kernel), ale ja omówię przypadek ogólny.

Wersja Major to główna wersja programu. Jest to numer linii kodu, która jest zwarta koncepcyjnie i rozwojowo. Zmienia się bardzo rzadko, najczęściej w wyniku zmiany koncepcji, założeń, API, podejścia itp. Najczęściej wiąże się z porzuceniem poprzedniej linii i pisaniem kodu od zera.

Wersja Minor opisuje kolejne etapy rozwoju programu, w ramach tej samej koncepcji (wersji Major). Zmienia się razem z zaimplementowaniem nowej funkcjonalności, zmianą jakiejś istniejącej itp. Na tym etapie są często realizowane punkty TODO programu – razem z zaimplementowaniem kolejnej funkcjonalności podnosi się wersję Minor.

Wersja Release mówi którym wydaniem w ramach wersji Minor jest dana paczka programu. To ten numer rośnie najczęściej – razem z wydaniem kolejnej wersji. Tutaj zachodzą zmiany wynikające z poprawek błędów, integracji łatek, wkładania kolejnych fragmentów kodu do repozytorium projektu. Na tym etapie realizowane są punkty BUGS.

Przyjęło się zapisywać te numery kolejno po sobie, rozdzielając je kropkami. A więc projekt Linux w wersji Major = 2, Minor = 8 i Release = 11 zapisujemy: Linux 2.8.11.

Kiedy developerzy danego projektu, podczas ciągłego rozwoju programu, dojdą do wniosku, że osiągnęli już kolejny punkt założeń projektowych, wydzielają w systemie kontroli wersji kolejną wersję Minor (linię produktu) i to w niej nanoszą zmiany, a linia poprzednia jest zamrożona i na nią nanoszone są jedynie poprawki istniejących tam błędów.

Często przyjmuje się praktyke przyjmowania parzystych numerów wersji Minor jako linie stabilne projektu, a nieparzyste jako linie rozwojowe. Pozwala to na rozwijanie projektu w rozwojowej linii np. 2.9 a z punktem osiągnięcia założeń rozwojowych linii (zaimplementowania założonych funkcjonalności), numer wersji zostaje podbity to 2.10, oraz od razu zostaje wydzielona wersja 2.11 w której następuje dalszy rozwój, a na wersję 2.10 nanoszone są już tylko poprawki błędów (równolegle z linią 2.11). Pozwala to użytkownikom oprogramowania na używanie wersji stabilnych, bez niespodzianek, powstających naturalnie w wyniku rozwoju programu, a developerom na bezstresowe nanoszenie poprawek, bez obawy zepsucia programu u wszystkich. (Oczywiście uzytkownicy o duchu Indiana Jones’a mogą również używać linii rozwojowej, ale na własne ryzyko. Wielu to robi i dostarcza developerom informacji o błędach.)

Warto wspomnieć jeszcze o praktyce tzw. nightly-builds. Duże, rozbudowane projekty praktykują przebudowywanie kodu całego projektu podczas nocy (na specjalnych farmach builderów) aby sprawdzić, czy repozytorium kodu jest spójne (czy developerów nie czekają niespodzianki podczas rozwoju). Automat budujący znakuje wtedy najczęściej dany build programu numerem kolejnym, co pozwala potem śledzić buildy np. przy rozpatrywaniu zgłoszonych błędów. Tutaj praktyka zapisywania jest różna, ale najczęściej spotykam się po prostu z kolejnym numerem po kropce, np. foobar 4.13.62.2173.

Mam nadzieję, że ten krótki przegląd numeracji ułatwi wam poruszanie się w tym gąszczu numerków.