# Válasszuk ki a nekünk igazán megfelelő FreeBSD verziót!

### A FreeBSD Dokumentációs Projekt

Copyright © 2005 A FreeBSD Dokumentációs Projekt

$FreeBSD: release/9.1.0/hu_HU.ISO8859-2/articles/version-guide/article.sgml 38826 2012-05-17 19:12:14Z hrs $

A FreeBSD a FreeBSD Foundation bejegyzett védjegye.

Ön a FreeBSD telepítését választotta. Üdvözöljük! Ezt a leírást annak szellemében készítettük, hogy segítsünk eligazodni a telepíthető verziók között.

Fordította: Páli Gábor, utolsó ellenőrzés: 2010.11.28.

[ Fejezetekre darabolt dokumentum / Teljes dokumentum ]

## 1. Háttér

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.

### 1.1. Kiadások

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.

### 1.2. Fejlesztési ágak

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.

### 1.3. STABLE vagy CURRENT?

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.

### 1.4. Portok vagy csomagok?

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).

## 2. Ahogy eddig ütemeztük a kiadásokat

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.

## 3. Ahogyan majd szeretnénk ütemezni a kiadásokat

Í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á:

http://www.FreeBSD.org/releng/index.html#schedule

  The Release Engineering Schedule

http://www.FreeBSD.org/security/security.html#supported-branches

  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.

## 4. Hogyan befolyásolják ezek a tényezők a döntésünket?

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.

## 5. Végszó

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>.