Product SiteDocumentation Site

1.6. En utgåvas livscykel

Projektet kommer samtidigt ha 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 bättre förståelse, låt oss titta närmare på ett programs resa, från dess initiala 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 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 (förutom 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.

1.6.2. Statusen Unstable

Låt oss återgå till fallet med 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. Detta första steg omfattar inspektion och validering från ftpmasters. Programvaran finns sedan tillgänglig i distributionen Unstable , vilket är distributionen med mjukvara "på utvecklingens knivspetts" och som väljs av användare som mer bryr sig om att ha senaste paketen än bekymrar sig för allvarliga fel. De upptäcker programmet och testar det sen.
Om de stöter på fel rapporterar de till paketets ansvariga. Ansvariga förbereder sedan rättade versioner som sedan skickas upp till servern.
Every newly updated package is updated on all Debian mirrors around the world within six hours. The users then test the corrections and search for other problems resulting from the modifications. Several updates may then occur rapidly. During these times, autobuilder robots come into action. The maintainer uploads the package sources (without any precompiled package). The autobuilders take over and automatically compile versions for all supported architectures. Some compilations may fail; the maintainer will then receive a bug report indicating the problem, which is then to be corrected in the next versions. When the bug is discovered by a specialist for the architecture in question, the bug report may come with a patch ready to use.
Kompilering av ett paket av autobuilder

Figur 1.2. Kompilering av ett paket av autobuilder

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å:
  1. lyckad kompilering på alla officiellt stödda arkitekturer;
  2. avsaknad av kritiska fel, eller åtminstonde mindre än aktuell version inkluderad iTesting;
  3. minst 5 dagar i Unstable, vilket vanligtvis är tillräckligt med tid för att hitta och rapportera allvarliga problem (om paketets egna testprotokoll bifogas, om det finns några framtagna, kan tiden minskas);
  4. beroenden som kan tillfredsställas i Testing, eller som åtminstonden kan flyttas dit tillsammans med paketet i fråga;
  5. automatiskt kvalitetstest av paketet (autopkgtest) — om definierad — visar ingen återgång.
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 har underhållaren utfört sitt arbete. Nästa steg är att inkludera den iStable-ditributionen som i verkligheten är en kopia av Testing skapad vid en vald tidpunkt, vald av utgåveadministratören. Idealt sker detta beslut när installeraren är redo och inget program i Testing har några kända kritiska fel.
Eftersom detta aldrig inträffar i praktiken måste Debian kompromissa: ta bort paket vars underhållare har misslyckats med att laga fel i tid, eller besluta att släppa en utgåva med en del fel i en eller flera av dess tusentals program. Utgåveadminstratören kommer sen tidiagare ha aviserat 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.
Ett pakets resa genom de olika Debian-versionerna

Figur 1.3. Ett pakets resa genom de olika Debian-versionerna

After the release of a new stable version, the Stable Release Managers manage all further development (called “revisions”, ex: 12.1, 12.2, 12.3 for version 12). These updates systematically include all security patches. They will also include the most important corrections (the maintainer of a package must prove the gravity of the problem that they wish to correct in order to have their updates included).
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 heta versionen av GNOME; de kan välja Debian Stable vilket kommer göra dem glad. Slutanvändare, mer intresserade av de senaste versionerna av GNOME eller KDE Plasma än jättestabilitet, kommer att finna att Debian-Testing är en bra kompromiss mellan avsaknad av allvarliga brister och relativt uppdatera versioner av program. Slutligen, för utvecklare och avancerade användare som vill prova all den nyaste utvecklingen inom Debian är Unstable rykande hett, 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!
Kronologisk vägen för ett program paketerat av Debian

Figur 1.4. Kronologisk vägen för ett program paketerat av 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 3 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.
The Debian security team handles security support in the current Stable release and also in the Oldstable release (but only for as long as is needed to ensure one year of overlap with the current stable release). This amounts roughly to three years of support for each release. The Debian LTS team handles the last (two) years of security support so that each release benefits from at least 5 years of support and so that users can upgrade from version N to N+2, for example, from Debian 9 Stretch to Debian 11 Bullseye.