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.

Jedes aktualisierte Paket wird innerhalb von sechs Stunden weltweit auf allen Debian-Spiegelservern auf diesen Stand gebracht. Die Anwender prüfen dann die Korrekturen und suchen nach anderen Problemen, die sich aus den Veränderungen ergeben. Mehrere Aktualisierungen können in schneller Folge stattfinden. Zu diesen Zeiten werden Selbstbau-Roboter eingesetzt. Der Betreuer hat in der Regel nur einen herkömmlichen Rechner und hat sein Paket auf einer amd64 (oder i386)-Architektur kompiliert (oder sie haben sich für einen reinen Quell-Upload entschieden, also ohne vorkompiliertes Paket); die Selbstbau-Roboter übernehmen es dann und kompilieren selbstständig Versionen für alle übrigen Architekturen. Möglicherweise scheitern einige Kompilierungen; der Betreuer erhält dann einen Fehlerbericht, der ihm das Problem anzeigt, das dann in der nächsten Version korrigiert wird. Wenn der Fehler von einem Spezialisten für die betreffende Architektur entdeckt wird, enthält der Fehlerbericht möglicherweise bereits eine gebrauchsfertige Nachbesserung.

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.

Nach der Veröffentlichung einer neuen stabilen Version leiten die Stable Release Manager die weitere Entwicklung („Revisionen“ genannt, zum Beispiel 7.1, 7.2, 7.3 für Version 7). Diese Aktualisierungen nehmen systematisch alle Sicherheitspatches auf. Sie schließen auch die wichtigsten Verbesserungen mit ein (der Betreuer eines Pakets muss die Schwere des Problems, das er korrigieren möchte, nachweisen, damit seine Aktualisierungen aufgenommen werden).

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.

Das Debian-Sicherheitsteam kümmert sich um die Sicherheitsunterstützung in der aktuellen Stable Release und auch in der Oldstable Release (aber nur so lange, wie es nötig ist, um eine einjährige Überlappung mit der aktuellen stabilen Version sicherzustellen). Dies entspricht etwa drei Jahren Support pro Release. Das Debian-LTS-Team kümmert sich um die letzten (zwei) Jahre Sicherheitssupport, sodass jede Release von mindestens 5 Jahren Support profitiert und Benutzer von Version N auf N+2 upgraden können, z.B. von Debian8 "Jessie" zu Debian 10 "Buster".