Po Internecie krąży wiele programów komputerowych. Wiele z nich jest interesujących i darmowych (na licencjach freeware czy też open source). Ale bardzo często latami są na bardzo wczesnym stadium swego rozwoju, określanego zbiorczo mianem wersji beta. Jaki jest cykl powstawania i życia programu komputerowego?
Po pracach projektowych program komputerowy wchodzi w etap wersji alfa. W tej wersji ciągle mogą być dodawane nowe funkcje, poprawiane są błędy. Czasem wręcz wycofuje się z niektórych rozwiązań. Te wersje z reguły nie wychodzą poza krąg programistów.
Później się przechodzi do etapu wersji beta, czyli wersji próbnych. Nie dodaje się tu nowych funkcjonalności programu, a tylko poprawki do tych, które zostały na końcu etapu wersji alfa. Wersje beta oddaje się do testowania wybranej grupie użytkowników, zwanej betatesterami. Coraz częściej publikuje się je także w Internecie (*). Mało kto jednak dodaje, że wersje beta ciągle mogą być pełne błędów, mało stabilne i pełne nieoptymalizowanego kodu. Nie zaleca się ich używania w systemach roboczych, to jest na komputerach gdzie są prowadzone istotne prace (na przykład wydawanie gazety). Wersje beta oznacza się jako 0.x.
Po usunięciu błędów nadchodzi czas na pierwszą stabilną wersję (release). W świecie linuxowców jest ona właśnie określana mianem stable. Wersja ta ma oznaczenie 1.0 i trafia już do użytkowników programu, jest rozprowadzana na CD-ROM, w Internecie i innymi sposobami. Niestety, praktycznie nie zdarza się, by nie pozostały w niej jakieś błędy. Nie ma co się temu dziwić, bo betatesterów jest mniej i stanowią mniej zróżnicowane środowisko niż grono ostatecznych użytkowników programu.
Od tego momentu prace nad programem ruszają dwutorowo, a nawet trzytorowo. Przede wszystkim wprowadza się i publikuje poprawki (updates), czyli takie wersje programu, które nie zawierają nowych możliwości, a tylko usuwają błędy. Zwykle oznacza się je jako 1.0x.
Drugim torem ruszają uaktualnienia (upgrades) do danej wersji, które zawierają pewne nowe możliwości, raczej niewielkie zmiany. Zwykle oznacza się je jako 1.x. Stosuje się też określenie łatka (patch).
Wreszcie równolegle prowadzi się prace nad nową wersją programu (2.0), która w założeniu ma mieć znaczące ulepszenia, dodatki, zmiany o które prosili użytkownicy. Takie wersje ukazują się nie częściej niż co kilka lat. I wtedy znów od wersji alfa…
Wiele programów dostępnych w Internecie ma funkcję automatycznego pobierania nowych wersji. Ich użytkownik nie musi więc zagłębiać się w gąszcz poprawek i uaktualnień. Dla innych zaleca się: jeśli twój program działa dobrze, nie instaluj danej poprawki; jeśli nie chcesz danej nowej funkcji, nie instaluj nowego uaktualnienia.
Oddzielną sprawą są poprawki bezpieczeństwa (security patches)…
* Pomiędzy wersją beta a wersją stabilną pojawia się wersja Release Candidate (RC), która trafia do zdecydowanie szerszego kręgu użytkowników. RC jest w założeniu wersją stabilną, która nie powinna się już zmienić. Może być więcej niż jeden RC. Jest on sygnałem, że programiści chcą wypuścić wersję stabilną.
Panowie (i Panie :)) z Yahoo! ładnie to opisali przy okazji tłumacząc konwencje numerowania, jaką oni stosują:
“In the software industry we will typically use the following letters to represent
the status of a project.
d or x – Development or Experimental (1.0d12)
This means you’ve just started working on a project where any
and all of the features could change at any time.
a – Alpha (1.0a6)
This is where you’ve nailed down your features, but you’re may
still be adding new ones as you go along. Also you might be
“feature complete” but the features are not yet fully implemented
to specification.
b – Beta (1.0b3)
When you’re in Beta, you’re typically “feature complete”, but there
are still many bugs and performance issues with your software.
You don’t usually release beta software to the end user unless
you’re looking for specific feedback about the product, or are in
need of help squashing bugs.
fc – Final Candidate (1.0fc1)
When you hit Final Candidate, you’re pretty sure you’ve squashed
any lingering bugs, and you’re about to release your software.
Your testers, however, may not agree, thus you can end up rolling
a few fc builds in an effort to wrap up a version.
GM – Golden Master (1.0)
This is the final, shipping version of your product. This is the
version that the public gets to play with, and the version that’s free
of any bugs that are known to cause problems (yeah, right).”
(wzięte z SDK Yahoo! Widgets)
Dziękuję Lukaszowi za uzupełnienia, szczególnie co do konwencji numeracji wersji alfa i beta… tyle się ich naoglądałem, a zapomniałem o tym :(
fc wydaje się odpowiednikiem RC (konwencji stosowanej przez Microsoft, ale chyba nie tylko).