Lassen Sie uns zunächst einen Blick auf den besonderen Fall der Distribution Experimental werfen: Dies ist eine Gruppe von Debian-Paketen, die der aktuell noch in Entwicklung befindlichen und nicht unbedingt fertiggestellten Programme entspricht, was ihren Namen erklärt. Nicht alles durchläuft diese Phase; manche Entwickler stellen hier Pakete ein, um Rückmeldungen von erfahreneren (oder mutigeren) Anwendern zu erhalten.

Andererseits enthält diese Distribution häufig wichtige Änderungen grundlegender Pakete, deren Aufnahme in Unstable mit schwerwiegenden Fehlern gefährliche Auswirkungen haben würde. Sie ist daher eine vollständig isolierte Distribution. Ihre Pakete werden niemals in eine andere Version übertragen (es sei denn durch direktes ausdrückliches Eingreifen des Betreuers oder der FTP Master). Auch ist sie nicht vollständig: nur eine Untermenge der vorhandenen Pakete ist in Experimental enthalten und es fehlt grundsätzlich das Basis-System. Diese Distribution ist deshalb meist nur zusammen mit einer vollständigen Distribution, wie beispielsweise Unstable sinnvoll einsetzbar.

Lassen Sie uns zum Fall eines typischen Pakets zurückkehren. Der Betreuer erstellt ein erstes Paket, das er für die Version Unstable kompiliert und auf den Server ftp-master.debian.org legt. Dieser erste Schritt schließt eine Überprüfung und Bewertung durch die FTP-Master ein. Die Software ist dann in der Distribution Unstable verfügbar, die eine Vorreiterrolle spielt und die von Anwendern gewählt wird, die mehr Wert auf aktuelle Paketen nach dem neuesten Stand legen, als sich um schwerwiegende Fehler zu sorgen. Sobald sie das Programm entdecken, probieren sie es aus.

Falls sie Fehler entdecken, melden Sie sie dem Paketbetreuer. Der Betreuer erstellt dann regelmäßig korrigierte Versionen, die er auf den Server hochlädt.

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.

Etwas später wird das Paket ausgereift sein; es wird in seinen Kompilierungen für alle Architekturen keine neuerlichen Veränderungen mehr durchgemacht haben. Damit ist es ein Kandidat für die Aufnahme in die Distribution Testing - einer Gruppe von Unstable-Paketen, die unter Beachtung einer Reihe von quantifizierbaren Kriterien ausgewählt worden sind. Jeden Tag wählt ein Programm unter Berücksichtigung von Elementen, die ein bestimmtes Qualitätsniveau gewährleisten, selbstständig die Pakete für die Aufnahme in Testing aus:

Dieses System ist sicherlich nicht unfehlbar; kritische Fehler werden regelmäßig in Paketen gefunden, die in Testing enthalten sind. Dennoch ist es im Allgemeinen effektiv, und Testing bereitet deutlich weniger Probleme als Unstable, womit es für viele ein guter Kompromiss zwischen Stabilität und Aktualität ist.

Angenommen, unser Paket ist jetzt in Testing enthalten. Solange es noch Optimierungspotenzial enthält, muss sein Betreuer es weiter verbessern und den Prozess von Unstable aus neu beginnen. (Jedoch erfolgt seine spätere Aufnahme in Testing normalerweise schneller: Falls es sich nicht erheblich verändert hat, sind alle seine Abhängigkeiten bereits erfüllt). Wenn es fertig ist, hat der Betreuer seine Aufgabe erfüllt. Der nächste Schritt besteht dann in seiner Aufnahme in die Distribution Stable, die eigentlich nur eine einfache Kopie von Testing zu einem vom Release Manager bestimmten Zeitpunkt ist. Idealerweise wird diese Entscheidung getroffen, wenn das Installationsprogramm fertig ist und wenn kein Programm mehr in Testing irgendwelche bekannten kritischen Fehler hat.

Da dies niemals wirklich eintritt, muss Debian in der Praxis Kompromisse machen: Pakete entfernen, deren Betreuer Fehler nicht rechtzeitig behoben hat, oder der Veröffentlichung einer Distribution mit einigen wenigen Fehlern in Tausenden von Programmen zustimmen. Der Release Manager wird zuvor einen Zeitraum mit einer Veränderungssperre verkündet haben, währenddessen jede weitere Aktualisierung in Testing genehmigt werden muss. Dies geschieht mit dem Ziel, neue Versionen (und damit neue Fehler) zu verhindern und nur solche Aktualisierungen zu genehmigen, die Fehler beheben.

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

Am Ende seiner Reise ist unser hypothetisches Paket in der stabilen Distribution enthalten. Dieser Weg, der nicht ohne Schwierigkeiten war, erklärt die erheblichen Verzögerungen, durch die die Debian-Stable-Veröffentlichungen voneinander getrennt sind. Dies trägt insgesamt zu ihrem Ruf hoher Qualität bei. Außerdem ist die Mehrheit der Anwender damit zufrieden, eine der drei gleichzeitig verfügbaren Distributionen verwenden zu können. Die Systemadministratoren, die vor allem um die Stabilität ihrer Server besorgt sind, benötigen nicht unbedingt die jüngste und beste Version von GNOME; sie können Debian Stable nehmen und werden damit zufrieden sein. Endnutzer, die mehr an den jüngsten Versionen von GNOME oder KDE Plasma als an felsenfester Stabilität interessiert sind, werden feststellen, dass Debian Testing ein guter Kompromiss zwischen der Abwesenheit schwerwiegender Probleme und relativ aktueller Software ist. Schließlich werden Entwickler und erfahrenere Nutzer den Weg bahnen, indem sie die neuesten Entwicklungen in Debian Unstable ausprobieren, sobald sie die Startbox verlassen haben, selbst auf die Gefahr hin, an Kopfschmerzen und Fehlern zu leiden, die zu jeder neuen Version eines Programms dazu gehören. Jedem sein eigenes Debian!

Jede Stable Release hat eine erwartete Lebensdauer von ca. 5 Jahren und da Releases tendenziell alle 2 Jahre stattfinden, kann es bis zu 3 unterstützte Releases zu einem bestimmten Zeitpunkt geben. Wenn eine neue stabile Version erscheint, wird die frühere Version zu Oldstable und die vorherige wird zu Oldoldstable.

Diese Langzeitunterstützung (LTS) von Debian-Releases ist eine neue Initiative: Einzelne Mitwirkende und Unternehmen schlossen sich zusammen, um das Debian-LTS-Team zu gründen. Ältere Releases, die nicht mehr vom Debian-Sicherheitsteam unterstützt werden, fallen unter die Verantwortung dieses neuen Teams.

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.