1.6. En utgåvas livscykel
Projektet har samtidigt tre till sex olika verison av varje program namngivna Experimental, Unstable, Testing, Stable, Oldstable, och till och med Oldoldstable. Var och en av dem motsvarar en fas i utvecklingen. För en god förståelse ska vi titta närmare på ett programs resa, från dess paketering till att det inkluderas i en stabil utgåva av Debian.
1.6.1. Statusen Experimental
Låt oss först ta en närmare titt på Experimental. Dess namn förklaras av att det är en grupp Debianpaket som motsvarar programvaran under utveckling just nu, och nödvändigtvis inte är färdiga. Inte allt passerar detta steg; en del utvecklare lägger till paket för att kunna få återkoppling från erfarna, modiga användare.
Annars huserar denna denna distribution ofta viktiga ändringar i baspaket, vars integration i Unstable med allvarliga fel skulle kunna ha kritiska konsekvenser. Den är därmed en helt isolerat distribution, vars paket aldrig migrerar till en annan version (flrutom genom direkt inblandning från förvaltare eller ftpmaster). Den är inte heller isolerad; endast en mängd av de existerande paketen finns i Experimental, och den innehåller vanligen inte grundsystemet. Denna distribution är därför mest använd i kombination med en annan self-contained version som Unstable.
Låt oss ta ett typiskt paket. Ansvarige skapar ett initialt paket som de kompilerar för versionen Unstable- och lägger den på servern ftp-master.debian.org
. Det omfattar inspektion och validering från ftpmasters. Programvaran finns sedan tillgänglig i distributionen i framkant, Unstable vald av användare som mer bryr sig om att ha uppdaterade paket än allvarliga programfel. De testar programmet.
Om de stöter på fel rapporterar de till paketets ansvariga. Ansvariga förbereder sedan rättade versioner som sedan skickas upp till servern.
Varje nytt uppdaterat paket uppdateras, inom 6 timmar, på alla Debian-speglar. Användarna kan sedan testa rättningarna och leta efter andra problem som härstammar från ändringarna. Flera uppdateringar kan ske snabbt. Under denna tid kommer autobuilder-robotar igång. Vanligen har underhållaren endast en traditionell dator, och har kompilerat sitt paket på amd64- (eller i386)-arkitektur; autobuilders tar över och kompilerar automatiskt versioner för alla andra arkitekturer. En del kompileringar kan misslyckas; ansvarige kommer då att få en felrapport som visar på problemet, vilket redan kan rättas i nästa version. När felet är identifierat av en arkitekturspecialist kan felrapporten komma med en programfix redo att använda.
1.6.3. Migration till Testing
Senare kommer paketet att ha mognat; kompilerat för alla arkitekturer kommer den inte att ha nyare ändringar. Det är nu en kandidat för att inkluderas i distributionen Testing - en grupp av paket från Unstable, valda efter något mätbart kriterium. Varje dag väljer ett program automatiskt paket som ska inkluderas i Testing enligt element som garanterar en viss kvalitetsnivå:
avsaknad av kritiska fel, eller åtminstonde mindre än aktuell version inkluderad iTesting;
minst 10 dagar i Unstable, vilket är tillräckligt med tid för att hitta och rapportera allvarliga problem;
lyckad kompilering på alla officiellt stödda arkitekturer;
beroenden som kan tillfredsställas i Testing, eller som åtminstonden kan flyttas dit tillsammans med paketet i fråga.
Detta system är inte ofalerbart; kritiska fel hittas regelbundet i paket inkluderade i Testing. Det är åndå oftast effektivt och Testing har långt färre problem änUnstable, vilket ger en bra avvägning mellan stabilitet och nyfikenhet.
1.6.4. Förflytta Testing till Stable
Låt oss anta att vårt paket nu inkluderas i Testing. Så länge det finns rum för förbättringar måste dess ansvariga fortsätta att förbättra det och starta om processen från Unstable (men att senare få den med i Testing går vanligtvis snabbare: om den inte har ändrats rejält är alla dess beroenden redan tillgänglig). När den når perfektion måste udnerhållare gjort klart jobbet. Nästa steg är att inkludera den iStable-ditributionen som i verkligheten är en kopia av Testing vid en vald tidpunkt, vald av utgåveadministratören. Idealt sker detta beslut när installeraren är redo och inget program i Testing harnågra kända kritiska fel.
Eftersom detta aldrig inträffar i praktiken måste Debian kompromissa: ta bort paket vara underhållare har misslyckats med att laga fel i tid, eller besluta att släppa en utgåva med en del fel i. Utgåveadminstratören kommer att tidiagare ha avisert ut en frys-period, under vilken varje uppdatering i Testing måste godkännas. Syftet är här att föhindra att någon ny version (med nya fel) och endast tillåta att uppdateringar lagar fel.
Efter utgivningen av en ny stabil version hanterar utgåveadministratören för stable all vidare utveckling (kallad revisioner, ex:7.1, 7.2, 7.3 för version 7). Dessa uppdateringar inkluderar alla säkerhetsuppdateringar. Det kommer också att innehålla de viktigaste rättningarna (paketunderhållaren måste bevisa allvaret i det problem de önskar korrigera för att få med sina uppdateringar).
Vid resans slut följer vårt hypotetiska paket med i den stabila distributionen. Denna resa, inte utan svårigheter, förklarar fördröjningarna mellan utgåvor av Debian Stable. Detta bidrar allmänt till dess rykte om kvalitet. Vidare, de flesta användare är nöjda med att använda en av de tre distributionerna som samtidigt finns tillgängliga. Systemadministratörer, som främst vill ha stabilitet på sina servrar behöver inte den senaste och nyaste versionen av GNOME; de kan välja Debian Stable,och de kommer att bli nöjda. Slutanvändare, mer intresserade av de senaste versionerna av GNOME eller KDE än jättestabilitet kommer att finna Debian-Testing att vara en bra kompromiss mellan senare versioner av program och säkerhetsfixar. Slutligen, för utvecklare och avancerade användare som vill prova all den nyaste utvecklingen i Debian är Unstable rykande färsk, med en viss risk för att orsaka migrån och fel i nya versioner av program. För var och en deras egna Debian!
1.6.5. Status Oldstable och Oldoldstable
Varje Stable-utgåva har en förväntad livstid på ungefär 5 år och givet att utgåvor brukar ske vart annat år kan det finnas upp till 4 stödda utgåvor vid varje given tidpunkt. När en ny stabil utgåva sker blir den föregående utgåvan Oldstable, och den före det blir Oldoldstable.
Long Term Support (LTS) för Debian-utgåvor är ett nytt initiativ: individuella bidragsgivare och företag gick samman för att skapa teamet Debian LTS. Äldre utgpvor som inte längre stöds av Debians säkehetsteam hamnar under ansvaret från detta nya team.
Debians säkerhetsteam hanterar säkerhetsstöd i aktuell
Stable-utgåve och också i
Oldstable-utgåvan (men bara så länge det behövs för att försäkra sig om ett års överlapp med aktuell stabil utgåva) Detta resulterar i cirka tre års support för varje utgåva. Debian LTS-team hanterar de sista två åren av säkerhetssupport så att varje utgåva erhåller minst 5 års support och så att användare kan uppgradera från version N till N+2.