Nejdříve nám dovolte vás nechat nahlédnout do případu Experimentální distribuce: je to skupina debianovských balíčků odpovídajících softwaru v současné době ve vývoji a ne nutně kompletních, což vysvětluje jejich pojmenování. Ne vše projde tímto krokem; někteří vývojáři sem přidávají balíčky za účelem získání zpětné vazby od zkušenějších (nebo odvážnějších) uživatelů.

Jinak, tato distribuce často uchovává důležité modifikace základních balíčků, jejichž začlenění do Nestabilní, se závažnými chybami, by mělo kritické následky. Je to tak úplně uzavřená distribuce, jejíž balíčky nikdy nepřejdou do jiné verze (kromě přímého, zvláštního zásahu správce nebo ftpmastera). Není také soběstačná: pouze část existujících balíčků je přítomna v Experimentální a celkově nezahrnuje základní systém. Tato distribuce je tak nejvíce použitelná v kombinaci s jinou, soběstačnou distribucí, jako je Nestabilní.

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.

Pokud narazí na chybu, nahlásí ji správci balíčku. Správce poté obvykle připraví opravené verze, které se nahrají na server.

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.

Po chvíli, balíček dospěl; sestaven na všechny architektury, ještě nepodstoupil poslední úpravy. Je tedy uchazečem o zařazení do Testovací distribuce - skupiny nestabilních balíčků, vybraných podle jistých kvalifikačních kritérií. Každý den program automaticky vybere balíčky k zařazení do Testovací, na základě prvků, které zaručují určitou úroveň kvality:

Tento systém není úplně neomylný; závažné chyby se pravidelně vyskytují v balíčcích zahrnutých do Testovací. Přesto, je to obvykle efektivní a Testovací vykazuje daleko méně problémů než Nestabilní a pro mnohé, je dobrým kompromisem mezi stabilitou a novinkami.

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.

Protože tento moment ve skutečnosti nikdy opravdu nenastane, musí Debian dělat kompromisy: odstranit balíčky, jejichž správce neopravil chyby včas nebo odsouhlasit vydání distribuce s nějakými chybami v tisícovkách programů. Manažer vydání dopředu oznámí období klidu, během kterého musí být každá aktualizace do Testovací schválena. Účelem je předejít novým verzím (a jejich chybám) a pouze schválit aktualizace, které opravují chyby.

After the release of a new stable version, the Stable Release Managers manage all further development (called “revisions”, ex: 10.1, 10.2, 10.3 for version 10). 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!

Každé Stabilní vydání mý předpokládanou životnost kolem pěti let a za předpokladu, že vydání zpravidla přicházejí co dva roky, se mohou vyskytovat až 3 podporovaná vydání v jeden časový okamžik. Jakmile vyjde nové vydání, původní se stane Starostabilní a to předešlé Starostarostabilní.

Tato dlouhodobá podpora (LTS) vydání Debianu je současnou iniciativou: jednotliví přispěvatelé a firmy spojili síly k vytvoření LTS týmu Debianu. Starší vydání, která už nejsou podporovaná bezpečnostním týmem Debianu spadnou do pravomoce tohoto nového týmu.

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.