Prima di tutto diamo un'occhiata al particolare caso della distribuzione Experimental: consiste in un gruppo di pacchetti Debian relativi a software in corso di sviluppo, e come dice il nome non necessariamente completato. Non tutto passa attraverso questa fase, alcuni sviluppatori scelgono di aggiungere i pacchetti in questa versione per ottenere un feedback dagli utenti più esperti (o coraggiosi).

In alternativa, questa distribuzione ospita spesso importanti modifiche ai pacchetti base, la cui integrazione con gravi bug nella versione Unstable avrebbe ripercussioni critiche. Si tratta, dunque, di una distribuzione completamente isolata, i suoi pacchetti non migreranno mai verso un'altra versione (se non per l'intervento esplicito del manutentore o deglii ftpmaster). Inoltre non è autosufficiente: solo un sottoinsieme dei pacchetti esistenti sono presenti nella versione Experimental, e generalmente non include il sistema di base. Questa distribuzione è quindi particolarmente utile in combinazione con un'altra distribuzione, indipendente, come Unstable.

Torniamo al caso di un pacchetto normale. Il manutentore crea un pacchetto iniziale, che compila per la versione Unstable e lo carica sul server ftp-master.debian.org. La prima operazione consiste in un esame e nella convalida da parte degli ftpmaster. Il software risulta disponibile nella distribuzione Unstable che è rischiosa, ma è la "punta di diamante" delle distribuzioni scelte dagli utenti che sono più preoccuapti di avere pacchetti aggiornati che preoccupati per i gravi bug. Scoprono il programma e poi lo testano.

Se incontrano bug, li segnalano al manutentore del pacchetto. Il manutentore prepara regolarmente versioni corrette, che rende disponibili sul 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. 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.

Successivamente, il pacchetto sarà maturato; compilato in tutte le architetture, non avrà subito modifiche recenti. Diventa quindi candidato per l'inclusione nella distribuzione Testing: un gruppo di pacchetti della versione Unstable scelti in base ad alcuni criteri quantificabili. Automaticamente ogni giorno un programma seleziona i pacchetti da includere nella Testing, secondo elementi che garantiscono un certo livello di qualità:

Il sistema non è chiaramente infallibile; saltano fuori regolarmente bug critici nei pacchetti inclusi in Testing. Tuttavia, è generalmente efficace e Testing pone molti meno problemi rispetto a Unstable, risultando per molti utenti, un buon compromesso tra novità e stabilità.

Supponiamo che il nostro pacchetto sia ora incluso in Testing. Anche se ha margini di miglioramento, il manutentore deve continuare a migliorarlo e riavviare il processo dalla Unstable (ma la sua successiva inclusione nella Testing è generalmente più veloce: se non è stato cambiato in modo significativo, tutte le sue dipendenze sono già disponibili). Quando raggiunge la perfezione, il manutentore ha completato il proprio lavoro. La fase successiva è l'inclusione nella distribuzione Stable, che è in realtà una semplice copia della Testing al momento deciso dal Release Manager. Idealmente questa decisione viene presa quando il programma di installazione è pronto, e quando nessun programma in Testing contiene alcun bug critico conosciuto.

Dato che un momento simile non si verifica mai in realtà, in pratica Debian deve fare un compromesso: saranno rimossi i pacchetti il cui manutentore non è riuscito a correggere in tempo i bug, o si accetta di rilasciare una distribuzione con alcuni bug nelle migliaia di programmi. Il Release Manager avrà già annunciato in precedenza un periodo di freeze (congelamento), durante il quale ogni aggiornamento di Testing deve essere approvato. L'obiettivo è quello di evitare qualsiasi nuova versione (con i suoi nuovi bug), e di approvare solo aggiornamenti che correggono i bug.

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!

Ogni rilascio Stable ha una durata prevista di circa 5 anni e dato che i rilasci tendono ad avvenire ogni 2 anni, ci possono essere fino a 3 rilasci che devono essere supportati in un determinato momento. Quando viene rilasciata una nuova versione stabile, il precedente rilascio diventa Oldstable e quello ancora prima diventa Oldoldstable.

Questo Supporto a Lungo Termine (LTS) dei rilasci di Debian è un'iniziativa recente: singoli collaboratori e aziende hanno unito le forze per creare il gruppo LTS di Debian. I rilasci più vecchi che non sono più supportati dal team di sicurezza di Debian sono sotto la responsabilità di questo nuovo team.

Il team di sicurezza di Debian gestisce il supporto di sicurezza sull'attuale versione Stable ed anche sulla versione Oldstable (ma solo per il tempo strettamente necessario per garantire un anno di sovrapposizione con l'attuale versione stabile). Ciò equivale grosso modo a tre anni di supporto per ogni versione. The team LTS di Debian si occupa degli ultimi (due) anni di supporto di sicurezza in modo che ogni rilascio benefici di almeno 5 anni di assistenza e che gli utenti possano effetuare l'aggiornamento dalla versione N alla N+2.