A számítógép szoftvereinél (a programoknál) gyakran találkozhatunk olyan számokkal, mint az 1.2, a 0.5 vagy 2.1 beta, netán 4.5.0.2... Ezekre hozzáértő ismerőseink rögtön rávágják, hogy ez a verziószám – talán azt is hozzáteszik, hogy minél nagyobb, annál jobb. Ha nem elégszik meg ilyen sablonos válasszal, és szeretné érteni, miről van szó, olvassa el az alábbi írást.
Az egész verziószám dologra azért van szükség, mert a legtöbb szoftvert nem egyszerűen egyszer elkészítik és készen van, használhatjuk, hanem folyamatosan fejlesztik. Hogy erre miért van szükség, az programonként változó. Van, hogy csak a használat során felderített hibákat javítják benne, de van hogy a jellegéből adódóan szükség van egy folyamatos aktualizálásra (pl. az adótörvények változása miatt a számlázó programoknál) és van, hogy az operációs rendszerek változása miatt szükséges a módosítás, hogy az új környezetben is rendesen működjön a program. Általánosságban elmondhatjuk, hogy érdemes az újabb változatokat használnunk mindenből, mert ha már javítottak benne egy felfedezett hibát - az a régi változatokban még benne lehet.
A programozók egy szoftver fejlesztésénél gyakorlatilag annak előrehaladását jelzik a verziószámmal. Gyakran 0.1-es számmal kezdik, és 1.0-val jelölik az első hivatalos kiadást. Ha újragondolják, újraprogramozzák azt, így követheti azt a 2.0 változat, majd a 3.0, 4.0, 5.0 és így tovább. (A köznyelvbe ezért került át a 2.0 kifejezés, mint valaminek az újra kiadása javított változatban) No de miért nem nevezik 1-nek, 2-nek, 3-nak, 4-nek egyszerűen? Ennek az oka az, hogy a módosítások, javítások nem feltétlenül olyan nagyok, hogy új kiadásnak számítson - ugyanakkor nem lehet megvárni vele a következő kiadást, ezért a programozók meghatározzák, hogy mekkora mértékű volt a változás, és adnak neki mondjuk egy 1.1-es verziószámot. Ha megint módosítanak valamit, akkor mondjuk 1.2. Nem feltétlenül szoktak sorba menni, ha nagyobb változás volt, akkor rögtön mondhatják azt is, hogy mondjuk 1.5.
Találkozhatunk viszont bonyolultabb verziószámokkal, ami tulajdonképpen még tovább ragoznak. Pl. 1.5.3 - Ezzel gyakorlatilag még tovább bővítik a kört egy újabb számmal, ami a még kisebb változásokat jelöli. Tehát nem váltanak 1.5-ről 1.6-ra, hanem az egytizednyi lépés helyett csak három századnyit jelölnek, és így jelölik: 1.5.3. Ne lepődjünk meg, ha lesznek olyan programok, melyeknél öt ilyen számot vagy még többet látunk egymás után - a megfejtésükhöz mindössze azt kell tudnunk, hogy az első szám a legnagyobb helyiérték és hátrafele az egyre kisebbek. Vagyis ha két számot össze akarunk hasonlítani:
Mindkettő egyes, vagyis az első változat valamelyik továbbfejlesztett állapota - majd kettes mindkettőnek a második száma, vagyis megegyezőek. A harmadik számnál viszont már az első nagyobb szám, vagyis az lesz az újabb verziója a programnak. Vagyis az utolsó két számmal már nem kell foglalkoznunk, mert azok csak kisebb módosításokat jelentenek.
Alfa, Béta, Gamma...
Remélem még követik a fonalat, mert már csak egy dolgot kell ismerniük a biztos tájékozódáshoz. A verziószámok mellett ugyanis gyakran előfordulhat olyan megjelölés, hogy alfa, vagy csak egy a betű, illetve beta vagy b betű. Ezek a szoftverfejlesztés egyes szakaszait jelöli:
Alfa: A szoftver még csak az alapvető követelményeket látja el, gyakran nem rendelkezik minden programfunkcióval ami bele van tervezve, a széleskörű hibakeresés a kiadás célja, és rendszerint nem hozzák nyilvánosságra, csak szoftvertesztelők kapják meg. Azok a fejlesztők, akik viszont nem rendelkeznek nagy fejlesztői csapattal, gyakran az internetező közösséget kérik meg egy ilyen tesztelésre, ezért találkozhatunk ilyen változatokkal.
Béta: A beta verziójú szoftver általában már tartalmazza a legtöbb beletervezett funkciót, de még nem érett meg kiadásra. Általában bemutatókhoz használják, vagy a hibák nyílt feltárási időszakához. A zárt csoport helyett ugyanis itt már sokkal valószínűbb, hogy széles körben elérhetővé teszik, hogy minél több visszajelzést kapjanak. A beta verziójú szoftverben még fontos hibák lehetnek, vagy hiányozhatnak olyan funkciók, melyek hiánya miatt gondolták a fejlesztők, hogy nem kiadható.
Kiadásra jelölt (angolul: release candidate, röviden: RC) A szoftver ilyen megjelöléssel már kiadásra kész, hacsak nem jelentkeznek súlyos hibák. A funkciók ilyenkor már nem változnak, és a hibajavításon kívül nem nyúlnak a fejlesztők a kódjához. A dokumentáció és az adatfájlok még változhatnak.
Általánosságban elmondható, hogy érdemes a fenti fejlesztési verziókat elkerülnünk, ha nem vagyunk igazán hozzáértőek. Sok kellemetlenségtől megkímélhetjük magunkat, ha megvárjuk a végső kiadását a programnak, vagy ha már nem az első kiadása lesz, akkor egy korábbi változatot használunk addig. Ha viszont csak ilyen változatban érhető el egy számunkra nagyon fontos program, és megbízható a fejlesztő, ebben az esetben körültekintéssel használhatjuk a fenti változatokat is.
Egyes programoknál, például a Microsoft termékeknél a végső kiadásokat nem verziószám jelöli, hanem évszám vagy más elnevezés: Windows XP, Windows Vista, Office XP, Office 97, stb.
A kompatibilitás - magyarul helyettesíthetőség
Ha ugyanazt a szoftvert használjuk mi és mondjuk egy munkatársunk is, azt szeretnénk, ha át tudnánk neki adni olyan fájlt, melyet ő is tud használni. Egy dokumentumot, egy adatbázist vagy egy tervet. Igen ám, de ez könnyen meghiúsulhat az eltérő kiadások vagy a verziószámok miatt. Az alapelv az, hogy a programoknak „lefele kompatibilisnek" kell(ene) lenniük, ha ez teljesül, akkor egy újabb verziójú programmal gond nélkül olvasunk egy régebbi verzióval előállított fájlt. Ritkán viszont előfordul, hogy ezzel is probléma adódhat. Amivel viszont gyakrabban találkozhatunk, az az, hogy „felfele nem kompatibilisek" a szoftverek, vagyis ha a legújabb kiadással készítünk egy fájlt vele, a korábbi verzióval rendelkező számítógépen lehet nem fogjuk tudni megfelelően beolvasni.