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

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 in Testing mehr irgendwelche bekannten kritischen Fehler hat.

Da dieser Augenblick 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: 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!

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, so dass jede Release von mindestens 5 Jahren Support profitiert und Benutzer von Version N auf N+2 upgraden können.