Numeracja wersji oprogramowania

Numeracja wersji oprogramowania – określenie kolejności powstawania nowych wersji oprogramowania, pozwala na odróżnienie wersji między sobą. Zazwyczaj jest liczbą naturalną (np. numerowanie wersji od 1 lub według roku powstania), liczbą rzeczywistą lub zestawieniem kilku liczb naturalnych. W ostatnim przypadku kolejne liczby oddziela się zazwyczaj kropką, a ich znaczenie jest następujące:

• Major (numer główny),
• Minor (numer dodatkowy),
• Release (numer wydania),
• czasami Build (w przypadku tzw. nightly-build).

Poszczególne składniki są kolejno zwiększane podczas zmian w programie. Często projekty nie używają wszystkich składników albo nazywają je inaczej (np. jądro Linuksa).

Oznaczenia wersji

Major

Liczba major (ang. główna) to wspólne oznaczenie wszystkich wersji programu bazujących na tych samych założeniach, mechanizmach itd. Zmienia się bardzo rzadko, najczęściej w wyniku zmiany koncepcji, założeń, API, podejścia itp. Czasami wiąże się z porzuceniem poprzednio rozwijanego programu i pisaniem kodu na nowo.

Minor

Kolejnymi liczbami minor (ang. mniej ważna) oznacza się kolejne etapy rozwoju programu w ramach tej samej koncepcji (wersji major). Zmienia się razem z zaimplementowaniem nowej funkcji, zmianą jakiejś istniejącej itp. Na tym etapie są często realizowane punkty TODO programu – razem z zaimplementowaniem kolejnej funkcjonalności podnosi się numer minor.

Release

Używany niekiedy numer wydania (z ang. 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.

Konwencje

Przyjęło się zapisywać te numery kolejno po sobie, rozdzielając je kropkami. A więc numer wersji jądra Linuksa o liczbach major = 2, minor = 8 i release = 11 zapisujemy: Linux 2.8.11.

Często nie zapisuje się kropki pomiędzy liczbą minor i release.

Kiedy deweloperzy 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 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 (np. w przypadku środowiska graficznego GNOME) praktykuje się przyjmowanie parzystych numerów 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 do 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 deweloperom na bezstresowe nanoszenie poprawek, bez obawy zepsucia programu u wszystkich.

Nightly-builds

Warto wspomnieć jeszcze o praktyce tzw. nightly-builds. Duże, rozbudowane projekty praktykują przebudowywanie kodu całego projektu podczas nocy (na specjalnie zaprogramowanych komputerach) aby sprawdzić, czy repozytorium kodu jest spójne (czy deweloperów nie czekają niespodzianki podczas rozwoju). Automat budujący znakuje wtedy najczęściej daną kompilację programu kolejnym numerem, co pozwala potem śledzić kompilacje np. przy rozpatrywaniu zgłoszonych błędów. Tutaj praktyka zapisywania jest różna, ale najczęściej spotyka się po prostu kolejne numery oddzielane kropkami, np. foobar 4.13.62.2173.

FOSS

Programy FOSS (ang. Free, Open Source Software) 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.

Linki zewnętrzne

• Semantic Versioning 2.0.0 (ang. • pol.)