Copyright © 2005 A FreeBSD Dokumentációs Projekt
$FreeBSD: head/hu_HU.ISO8859-2/articles/version-guide/article.sgml 39544 2012-09-14 17:47:48Z gabor $
A leginkább megfelelő verzió kiválasztásához fontos megértenünk néhány alapvető fogalmat a FreeBSD fejlesztési modelljével és az ún. Release Engineering (RE, “kiadásépítés”) folyamatával kapcsolatosan.
A FreeBSD-t nagyrészt független önkéntesek hatalmas csoportja fejleszti. A rendszermag, a legalapvetőbb függvénykönyvtárak, valamint a hozzájuk tartozó segédprogramok forrásait egy verziókövető rendszerben tárolják, amely bárki által és bármikor tetszőlegesen letölthető. Ettől függetlenül ezek lefordított változatai (binárisai) is rendszeresen elérhetőek. Néhány ilyen binárist alapos és széleskörű tesztelési folyamatnak vetnek alá, majd kiadásnak címkézik fel őket.
A kiadások (release) általában rendelkeznek egy főverziószámmal és egy alverziószámmal.
A főverziószámok feladata, hogy jelezze az újabb, nagyobb változtatásokat a rendszerben. Ilyenkor természetesen elkerülhetetlen, hogy ennek következtében komolyabb átszervezéseken menjen át a FreeBSD, vagy éppen a régebbi, már hasztalannak tekintett részei eltűnjenek. Emiatt gyakran még a korábbi főbb kiadásokkal kapcsolatban is elveszhet bizonyos mértékű kompatibilitás.
Az alverziószámok jelzik a megbízhatóságot és a teljesítményt érintő kisebb hibajavításokat. Ebben az esetben mind a forráskód-, mind pedig a bináris szintű kompatibilitás megtartása egyik elsődleges feladatunk. Alkalmanként az alverziókba is kerülhetnek újítások, de csak akkor, ha ezek nem fenyegetik a velük szemben kitűzött összes többi célt.
Azonban sose szabad elfelejtenünk, hogy egy “kiadott verzió” nem több, mint a forrásról egy adott időben és egy adott néven (címkével ellátott) készített pillanatfelvétel. (Például az 5.4-es kiadáshoz a kiadásépítők a RELENG_5_4_0_RELEASE címkét tették.) A fejlesztés a HEAD néven ismert címkével azonban mindig halad tovább.
Minden kiadás alkalmával létrehoznak egy fejlesztési ágat, mint mondjuk a RELENG_5_4. Habár a RELENG_5_4_0_RELEASE címkével ellátott források már nem fognak a továbbiakban változni, a RELENG_5_4 címkével rendelkezők ellenben még igen, méghozzá a HEAD ágból származó biztonsági vagy egyéb javítások, esetleg kisebb változtatások nyomán.
Egy-egy főbb kiadáshoz még egy másik címkét is létrehoznak, mint mondjuk a RELENG_5. A biztonsági és egyéb javításokon túl más módosítások is áthozhatóak a HEAD ágból, így tulajdonképpen ez lesz az aktív ág, amikor a következő kiadást készítik elő az adott vonalban.
Minden egyes nagyobb kiadás életciklusában létrejön még egy további fejlesztési ág, amelyet STABLE-nek (megbízhatónak) neveznek. Ezzel jelzi a FreeBSD Projekt, hogy véleménye szerint az adott ágban szereplő módosítások minősége elegendő a szélesebb körű használathoz. Azokat az ágakat pedig, amelyeknek további tesztelésre van szükségük a komolyabb használathoz, CURRENT-nek (aktuálisnak) nevezik.
Megjegyzés: A FreeBSD Projekt nem tudja garantálni, hogy stable-ként szállított szoftverek elegendőek egy telepítéshez. Ezt mindenkinek magának kell eldöntenie. Nem szabad elfelejteni, hogy ez a projekt elsősorban önkéntesekből áll és nem képes a működésre semminemű szavatosságot vállalni.
Az említett állományokon kívül a FreeBSD még több ezernyi, külső fejlesztők által készített alkalmazásokat is támogat. (Ilyenek a különböző ablakkezelő rendszerek, böngészők, levelező kliensek, irodai programcsomagok, és így tovább.) Általánosságban véve nem a projekt maga fejleszti ezeket a szoftvereket, csupán egy keretrendszert biztosít a telepítésükhöz (amelyet Ports Collection-nek (“portgyűjtemények”) neveznek). Attól függően, ahogy ezt a licenszelésük megengedi, ezek az alkalmazások telepíthetőek forrásból (ezeket nevezik portoknak), vagy előre lefordított binárisokból (ezeket nevezik csomagoknak).
A FreeBSD 5.X verziójának fejlesztése és kiadása során sok-sok olyan tapasztalatot szereztünk, amelyek csak utólag váltak világossá számunkra. Az 5.X-es vonal célkitűzései meglehetősen agresszívek voltak és magukban foglalták a következőket:
Az SMP (Symmetric MultiProcessing) rendszerek támogatása
A teljesítmény növelése a kernelen belüli erőforrás-kiosztás egy új stratégia szerinti átdolgozásával
Számos új processzor architektúra támogatása
Egy új szálkezelési modell bevezetése
Egy új ütemező bevezetése
Új technológiák, mint például az energiagazdálkodás, támogatása (különösen laptopok esetén); és ami a legfontosabb:
Addig nem tekintjük ezt a vonalt STABLE-nek, amíg az imént felsorolt feladatok be nem fejeződnek.
Ez egy olyan helyzet kialakulásához vezetett, ahol évek teltek el a 4.X vonal STABLE és az 5.X vonal STABLE kiadásai között. Ez magával hozott néhány tényleges kellemetlenséget:
Az egyszerre kivitelezendő újításokhoz kapcsolódó módosítások nagy száma jelentős mértékben megnehezítette az egyes módosítások elkülönítését és beolvasztását a STABLE ágba.
Ez pedig azt jelentette, hogy azok a felhasználók, akiknek igazán szüksége volt bizonyos újításokra (például, hogy képesek legyenek futattni a rendszer egy modern hardveren), kényszerűen átálltak (mondjuk) a FreeBSD 5.2.1-es verziójára, annak ellenére, hogy az kifejezetten egy fejlesztői kiadás volt, és hogy CURRENT kiadás lévén nem felelt meg teljes egészében minden igényüknek.
A beolvasztások során a fejlesztők néha olyan helyzetbe kerültek, ahol olyan verzión kellett az újításaikat támogatniuk, amelyeket nem elsődleges fejlesztői platformként használtak.
A késés továbbá azt jelentette, hogy mire az 5.3 végre STABLE szintű kiadássá válhatott, az időközben felgyülemlett módosítások terhe kínszenvedéssé tette a frissítési folyamatot.
Úgy szólván senki sem volt elégedett ezzel az eredménnyel.
A következőket tanultuk mindezekből:
A főbb kiadásoknak kevesebb újítást kell tartalmazniuk és gyakrabban kell megjelenniük.
A lehető legjobban el kell szigetelni egymástól a különböző újításokhoz kapcsolódó módosításokat. (Ez egyben arra is utal, hogy bizonyos fejlesztéseket nem az aktív forrásokon belül végezni, és majd csak akkor beolvasztani őket, ha már nem veszélyeztetik egyik párhuzamos fejlesztést sem.)
A főbb kiadások határidejét inkább időben kell megszabni, nem pedig az újítások mértékében. Ha az egyes újítások nem készülnek el időre, akkor ki kell őket kapcsolni és meghagyni egy későbbi kiadásra.
Kevesebb újítással és gyakoribb megjelenéssel remélhetőleg csökkeni fog az egyes módosítások beolvasztásához szükséges idő a HEAD ágból a legfrissebb STABLE ágba (és ezáltal nem csak egyetlen fejlesztési vonalban maradnak támogathatók). Továbbá, mivel ezek az módosítások kellőképpen elszigeltek egymástól, az integrálás során keletkező hibák kockázata is csökken.
Sőt, az időben megkötött határidőknek köszönhetően végre könnyebben tervezhetnek előre a felhasználók, a külső alkalmazások fejlesztői és maguk a FreeBSD fejlesztői is egyaránt.
Íme a Projekt jelenlegi céljai az ütemezésben:
Minden 18 hónapban új főbb kiadás megjelentetése;
Minden 4 hónapban új kisebb kiadás megjelentetése;
Minden főbb kiadás legfrissebb kiadásához előkészített csomagokat nyújtani;
Minden főbb kiadás legutóbbi néhány kiadásához biztonsági frissítéseket és kritikus hibajavításokat (biztonsági fejlesztői ágak) nyújtani;
Tekintettel a telepíthető verziók kombinációjának nagy számára, nem lehet minden egyes verziót korlátlanul támogatni; ezt részben a rendelkezésre álló gépi erőforrások korlátozzák, de leginkább a projektben résztvevő önkéntesek által nyújtott segítség mennyisége.
Az érdeklődők figyelmébe ajánljuk továbbá:
The Release Engineering Schedule
The Security Branch Schedule
Az említett dokumentumok még nagyobb mélységben részletezik a tárgyalt hátteret, és feltárják azokat folyamatokat, amelyek a támogatott fejlesztői ágakat és azok élettartalmát illető döntéseket befolyásolják.
Az alábbi kérdések megválaszolása határozhatja meg a döntést a megfelelő verzió kiválasztásában:
Milyen mértékű megbízhatóságot várunk el a rendszertől?
Mennyire vagyunk hajlandóak frissíteni a rendszerünket?
Mennyire gyakran szeretnénk frissíteni a rendszerünket?
Mennyire fontos számunkra a biztonság?
Forráskódból vagy bináris állományokból akarunk telepíteni?
Szeretnénk részt venni a FreeBSD fejlesztésében?
Néhány további vázlatos útmutatás a döntéshez:
Ha rövid időn belül az elérhető legnagyobb mértékű megbízhatóságból szeretnénk profitálni, viszont nincs lehetőségünk frissíteni, akkor minden bizonnyal a legfrissebb STABLE jelzésű kiadást lenne hasznos feltelepítenünk és használnunk. Biztonsági igényeinknek megfelelően érdemes követni az adott kiadáshoz megjelenő javításokat.
Ha rövid időn belül vagy szükségünk van a legfrissebb újításokra vagy pedig a biztonsági javításokra, valamint az időt és erőforrást sem sajnáljuk a frissítésre, érdemes a legújabb STABLE ágat követnünk.
Ha nem kívánjuk közvetlenül élesben használni a rendszert és csak bizonyos problémák érdekelnek minket, valamint a következő nagyobb kiadás néhány hónapon belül megjelenik, valószínűleg érdemes elgondolkodni annak az ágnak telepítésén, ezzel is segítve a projektet a kiadás tesztelésében, megbízhatóvá tételében és úgy egyáltalán jobbá tenni a hosszú távú használatra.
Ha csak forrásból szeretnénk telepíteni és hibákat keresni az alaprendszerben, vagy éppen utánajárni az ismert hibáknak, illetve nyomon követni őket az ezzel kapcsolatos levelezőlistán, érdemes a HEAD fejlesztési ágat használnunk.
Reméljük, ez a leírás hasznos kiindulásnak szolgált a FreeBSD fejlesztési modelljének megértésében és az igényeinknek legjobban megfelelő verzió kiválasztásában!
Ha kérdése van a FreeBSD-vel kapcsolatban, a következő
címre írhat (angolul): <freebsd-questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése,
kérjük erre a címre írjon: <gabor@FreeBSD.org>.