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.
Let us turn back to the case of a typical package. The maintainer creates an initial package, which they compile for the Unstable version and place on the ftp-master.debian.org
server. This first event involves inspection and validation from the ftpmasters. The software is then available in the Unstable distribution, which is the “cutting edge” distribution chosen by users who are more concerned with having up-to-date packages than worried about serious bugs. They discover the program and then test it.
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. Most frequently, the maintainer has only one traditional PC and has compiled their package on the amd64 (or i386) architecture (or they opted for a source-only upload, thus without any precompiled package); the autobuilders take over and automatically compile versions for all the other 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.
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;
at least 5 days spent in Unstable, which is usually sufficient time to find and report any serious problems (successfully passing the package's own test suite, if it has one, reduces that time);
lyckad kompilering på alla officiellt stödda arkitekturer;
dependencies that can be satisfied in Testing, or that can at least be moved there together with the package in question;
automatic quality tests of the package (autopkgtest) — if defined — don't show any regression.
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
Let us suppose that our package is now included in Testing. As long as it has room for improvement, its maintainer must continue to improve it and restart the process from Unstable (but its later inclusion in Testing is generally faster: unless it changed significantly, all of its dependencies are already available). When it reaches perfection, the maintainer has completed their work. The next step is the inclusion in the Stable distribution, which is, in reality, a simple copy of Testing at a moment chosen by the Release Manager. Ideally, this decision is made when the installer is ready, and when no program in Testing has any known critical bugs.
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.
After the release of a new stable version, the Stable Release Managers manage all further development (called “revisions”, ex: 7.1, 7.2, 7.3 for version 7). 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).
At the end of the journey, our hypothetical package is now included in the stable distribution. This journey, not without its difficulties, explains the significant delays separating the Debian Stable releases. This contributes, over all, to its reputation for quality. Furthermore, the majority of users are satisfied using one of the three distributions simultaneously available. The system administrators, concerned above all about the stability of their servers, don't need the latest and greatest version of GNOME; they can choose Debian Stable, and they will be satisfied. End users, more interested in the latest versions of GNOME or KDE Plasma than in rock-solid stability, will find Debian Testing to be a good compromise between a lack of serious problems and relatively up-to-date software. Finally, developers and more experienced users may blaze the trail, testing all the latest developments in Debian Unstable right out of the gate, at the risk of suffering the headaches and bugs inherent in any new version of a program. To each their own 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.
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 releases benefits from at least 5 years of support and so that users can upgrade from version N to N+2, for example from Debian 8 "Jessie" to Debian 10 "Buster".