Bétától az RTM-ig: útmutató a szoftververziókhoz

Alfa, béta, update, service pack; 1.0, 2.0, 3.1, 3.11 - ugye ismerős? Ha rendszeresen töltöget le szoftvereket, akkor minden bizonnyal, de tudja is, hogy mi mit jelent? Segítünk eligazodni a szoftververziók és jelöléseik között, amelyek végigkísérik ezeknek a termékeknek az életciklusát.

Vigyázat, béta! Jó ideje együtt élünk az ilyen szoftverekkel, szájtokkal

A szoftverfejlesztés igen összetett folyamat, és ezt hűen jelzi az a jelölési rendszer is, amelyet a fejlesztők kidolgoztak az egyes fázisok azonosítására - és amelyeket mi is jól ismerhetünk a különböző rendelkezésre álló letöltésekből. A felhasználó legközvetlenebb ismerőse a béta: ha ezt a jelölést látjuk egy szoftver nevében, akkor rendszerint tudjuk, hogy egy tesztváltozatról van szó. Ennek megfelelően sokak számára ismerős lehet a "kijön bétából" kifejezés is, ami arra a momentumra utal, amikor megjelenik a szoftver végleges verziója, vagyis lekerül a neve mellől a béta szócska, jelezvén annak elkészültét.

Már ha egyáltalán ez bekövetkezik, hiszen a Google például előszeretettel tartja bétában az új szolgáltatásait - akár hosszú évekig. (Nem kis részben hozzájárulva ezzel a kifejezés ismertségének elterjedéséhez.) Sőt, az elmúlt években kimondottan divatos lett a "bétázás" a webkettes szolgáltatások körében: olyannyira, hogy magára valamit is adó új szájt nem is indult el úgy, hogy ne élte volna meg ezt a fázist.

A dolog magyarázatául persze szolgálhat az is, hogy az eleve közösségi szolgáltatásnak induló szájtokat - mint például a videomegosztók, közösségi oldalak - a fejlesztők már tényleg csak azok után tudják tökéletesre csiszolni, hogy a nagyközönség - akár több tízezer felhasználó - "belakta" azokat. Ez a folyamat pedig igen hosszú időt is igénybe vehet, mint arra már utaltunk is, nem csoda, hogy megszületett az "örök béta" kifejezés is, ami az ilyen, kvázi örökké elhúzódó tesztidőszakokra utal.

A csenevész pre-alfától a deltás kész verzióig

Béta viszont nem létezhet alfa (eredetiben alpha) nélkül, sőt, egy szoftver gyakran egyenesen a pre-alfának (pre-alpha) nevezett időszakban kezdi meg földi pályafutását. A két fázis közötti fő különbség az, hogy a pre-alfa, ha készül ilyen változat, a fejlesztőknek készül, és még egyáltalán nem biztos, hogy tartalmaz minden funkciót. Ha kicsit kézzel foghatóbban szeretnénk ezt érzékeltetni, azt mondhatjuk, hogy a pre-alfa idején még nem az a kérdés, hogy a szoftver jól működik-e, hanem az, hogy egyáltalán működik-e. A fejlesztők ilyenkor még a szoftver tervezése, fejlesztése, egyes elemeinek próbálgatása szintjén dolgoznak a művükön.

A nyílt forráskódú világban - a kézenfekvő példa a Linux operációs rendszer - megkülönböztetnek két különféle pre-alfa változatot. A milestone, vagyis mérföldkő-kiadás azt jelzi, hogy a fejlesztés egy fontos szakaszához érkezett azzal, hogy bizonyos funkciók bekerültek a szoftverbe. A nightly build (hajnali fordítás) egy olyan verziót jelöl, amely frissen, azon melegében került ki a fejlesztők keze közül az alapvető ellenőrzések után, hogy a tesztelők azonnal leellenőrizhessék az új funckiókat, kiszűrhessék a hibákat.

Egy fejlesztő a Google-nál: kihasználják rendesen a béta-időszakot

A pre-alfát követő alfa verzió már nem fejlesztők, hanem tesztelők kezébe kerül, de jellemzően még belső tesztelőkhöz. Az alfa és a már említett béta között pedig az az alapvető különbség, hogy a béta (eredetiben beta) az első olyan változat, amely a nagy nyilvánosság elé is kerülhet. A fejlesztőkhöz közeli tesztelők helyett a bétát már a jövendőbeli felhasználók, a gyártó reménybeli vevői, üzleti partnerei nyúzhatják és tanulmányozhatják tovább. A bétatesztelés elsődleges célja már az, hogy kiderüljön, mennyire használható a szoftver, és persze az, hogy a mindaddig rejtve maradt hibákat is orvosolni tudja a gyártó a visszajelzések alapján.

A Linux-verzióknak se szeri, se száma

Ugyan ekkor már nagyobb nyilvánosságról van szó, de ez a verzió még mindig nem biztos, hogy bárki számára elérhető: vannak zárt körű béta-tesztelések is, amikor a gyártó a tesztelők egy bizonyos kiválasztott körével dolgozik együtt. Ez is lehet azonban több száz, vagy több ezer ember, akikkel akár titoktartási szerződést is aláírathatnak. Természetesen, a fájlcserélőknek és szoftverkalózoknak, no meg a szerződésszegőknek hála, ezek a verziók ma már rendre kiszivárognak az interneten. (Mint például a Windows Vista korai tesztverziói.) Bár sok új alkalmazás igen kívánatos a felhasználók számára ebben a formában, azárt nem árt vigyázni: a szoftver bétában még tele lehet hibákkal, és a mi a fő gond, lehet igen instabil, összeomlásai pedig adatvesztéshez vezethetnek - vagyis munkára nem ajánlatos használni.

Ha a bétatesztek sikeresen lezárultak, akkor a szoftver az RC, vagyis release candidate (kiadásra jelölt) fázisba lép. Ebben a verzióban lehetnek még bugok, vagyis hibák, és a gyártó célja az utolsó apró problémák elhárítása. A görög ábécében tovább haladva, rendszerint gamma és delta névvel jelölik az alapvetően kész, de még tesztelés alatt álló verziókat, az omega és a zenith pedig azokat a verziókat jelzi, amelyek már elvileg hibátlanok, vagyis bármikor gyártásba kerülhetnek. A fejlesztők megkülönböztetik azt a fázist is, amikor a szoftver kódja elkészül (code complete fázis): ilyenkor módosítani még lehet, de további eredeti részletek már nem kerülnek hozzá.

Dobozba vele! - avagy az RTM és a GA

Kedvenc példánknál maradva, a maratoni ideig fejlesztett Windows Vista operációs rendszer esetében a fenti fázisok hosszú évekig húzódtak. Az utolsó szakaszban azonban, ha a szoftver elér idáig, kicsit felpörögnek a dolgok, és itt még hátra van két fázis. Az RTM, vagyis release to manufacturing (vagy marketing) az a verzió, amely már megfelel a gyártó által támasztott minőségi elvárásoknak, vagyis készen áll arra, hogy a "futószalagra", vagyis sokszorosításra kerüljön. Ezt a változatot a fejlesztők rendszerint egy aranyszínű (gold) master-lemezre írják fel, erről indul meg a sorozatgyártás.

Az utolsó fázis a General Availability (GA), ami azt jelenti, hogy ha a klasszikus példával élünk, a szoftver bedobozolva ott van a boltok polcain, vagy, ha csak a neten keresztól terjesztik, akkor letölthető, és bárki elérheti (a rövidítés szó szerint ezt jelenti).

Foltok és frissítések

Mivel a szoftver nem egészen olyan, mint a többi megszokott fogyasztási termék, a fejlesztők munkája ezzel még nem ér véget. Amíg csak a szoftver életciklusa tart, támogatást biztosítanak hozzá frissítések formájában. A számítógépes szaknyelv ezeket patch-nek (folt), vagy update-nek nevezi, és ezek célja többféle lehet. Alapvetően a frissítés működési vagy funkcionális hibákat javít ki, illetve biztonsági réseket foltoz be, de egy komolyabb update új funkciókat is hozzáadhat a szoftverhez, vagy megváltoztathatja annak egész működését.

A Windows operációs rendszer felhasználóinak ismerős lehet a Service Pack, vagyis szervizcsomag kifejezés is. Ez tulajdonképpen egy nagyobb frissítés, amely az újítások mellett az időközben kiadott biztonsági frissítéseket is tartalmazza. A Windows Vistához eddig egy, az XP-hez pedig három ilyen érkezett.

A verziószámok rendszere

Boltokban az NT 6.0

A különböző verziók követését a görög ábécé betűi és a funkcionális jelölések mellett a verziószámozás teszi lehetővé, amit a szoftver névjegyében tekinthetünk meg (rendszerint ez a programok menüjének legutolsó eleme, a Súgó/Help menüpont alatt, de gyakran indításkor is kiírják, vagy a fejlécben is megtalálható). A verziószám elemeit rendszerint pontokkal választják el egymástól, hasonlóan a tudományos szakmunkák fejezeteinek, alfejezeteinek számozásához. A leggyakrabban használt verziószám három tagú, vagyis valahogy így néz ki: 4.3.5.

Az első számjegy a fő verziót jelöli, és két ilyen között tulajdonképpen csak annyi a hasonlóság, hogy ugyanarról a termékről van szó: elképzelhető, hogy a forráskódot teljes egészében kidobják, és újraírják a fejlesztők. Az alverzió viszont, amit a második számjegy jelöl, már csak valamilyen fontos módosításban különbözik, mint például a már említett új funkciók. Bár a számok rendszerint folyamatosan nőnek, akár ugrásra is sor kerülhet, ha tényleg jelentős frissítésről volt szó. Így egy szoftver esetében az 1.2-es verziót akár az 1.5-ös is követheti, ha a fejlesztők látványosan jelezni szeretnék, hogy dolgoztak valamit.

A legutolsó helyen álló számjegy pedig csak valamilyen kisebb módosítást, javítást, foltozást jelöl, vagyis azt, hogy belenyúltak a programba, de semmi jelentőset nem műveltek vele. Emiatt értelemszerűen az alverzió számának nem kell növekednie, egy patch eredményezhet olyan változást is, hogy az 1.0-ból 1.0.1 lesz.

Az egyes gyártók persze különféleképpen bánnak a verziószámozási sémával is, és lehet, hogy a három tag helyett csak kettőt használnak (emlékszünk még a Windows 3.11-re?), vagy negyedikként odabiggyesztik az aktuális build (az éppen újrafordított változat) számát is, ha a program még fejlesztés alatt áll. Ugyanígy a verziószám jelölheti az alfa- vagy bétaállapotot, vagy az ezt követő fázisokat is (1.0b2, 1.0rc1). Emellett egyes gyártók egyedi megoldásokat is alkalmaznak, így például a kiadás dátumát rögzítik a verziószámban (például a 08.09 ez év szeptemberét jelöli ezzel a módszerrel), vagy sajátos terméknévvel rejtik el a kizárólag belső használatú verziószámot (a Windows XP például nem más, mint a Windows NT 5.1-es verziója, a Vista pedig a 6.0) - és még hosszasan sorolhatnánk.

A verziószámláló persze nem pörög felfelé bármeddig: minden szoftver (vagyis tulajdonképpen a fő verzió) eléri egyszer azt a kort, amikor már nem támogatják tovább, vagyis nincs több frissítés hozzá. Ekkor beszélünk az end of life (az életciklus vége) fázisról, amit angolul illetnek a vintage vagy legacy névvel is. Ha ez bekövetkezik, akkor tényleg érdemes frissíteni, vagy az újabb verzióra, vagy, ha az nincs, mert a termék megbukott, nem folytatják, vagy a gyártó csődbe ment, akkor valami teljesen másra. Az otthoni átlagfelhasználó persze nem valószínű, hogy ilyen sokáig koptatna egy szoftvert, hiszen mire ez bekövetkezik, addigra rendszerint a számítógépe is elavul.