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 degli 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ù preoccupati 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.

Ogni nuovo pacchetto aggiornato è aggiornato su tutti i mirror di Debian sparsi per il mondo in meno di sei ore. Gli utenti provano le correzioni e cercano altri problemi che potrebbero essere stati causati dalle modifiche. Potrebbero susseguirsi rapidamente molti aggiornamenti. Durante questo periodo entrano in azione i robot autobuilder. Il manutentore carica i sorgenti del pacchetto (senza alcun pacchetto precompilato); gli autobuilder provvedono automaticamente a compilare le versioni per tutte le architetture supportate. Alcune compilazioni potrebbero non andare a buon fine; il manutentore riceverà una segnalazione di bug nella quale vengono riportati gli errori riscontrati, che dovrà essere corretto nelle versioni successive. Quando il bug viene scoperto da uno specialista dell'architettura in questione, la segnalazione può essere accompagnata da una patch pronta all'uso.

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. Fino a quando 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.

Dopo il rilascio di una nuova versione stabile, lo Stable Release Manager ne gestisce gli ulteriori sviluppi (chiamate "revisioni", es: 10.1, 10.2, 10.3 per la versione 10). Questi aggiornamenti includono sistematicamente tutte le patch di sicurezza. Potranno anche includere correzioni più importanti (per poter includere aggiornamenti di un pacchetto, il manutentore deve dimostrare la gravità del problema che intende correggere).

Alla fine del percorso, il nostro ipotetico pacchetto viene incluso nella distribuzione Stable. Questo percorso, non senza difficoltà, spiega il notevole tempo che separa due rilasci di Debian Stable. Ciò contribuisce, nel complesso, alla sua reputazione di qualità. Inoltre, la maggior parte degli utenti si accontenta di utilizzare una delle tre distribuzioni disponibili contemporaneamente. Gli amministratori di sistema, preoccupati soprattutto per la stabilità dei loro server, non hanno la necessità di disporre dell'ultimissima e suprema versione di GNOME; possono scegliere Debian Stable e saranno soddisfatti. Gli utenti finali, più interessati alle ultime versioni di GNOME o KDE Plasma piuttosto che ad un sistema stabile e solido come una roccia, sceglieranno Debian Testing per avere un buon compromesso tra la mancanza di gravi problemi e un software abbastanza aggiornato. Infine, gli sviluppatori e gli utenti più esperti possono tracciare il sentiero, testando tutti gli ultimi sviluppi in Debian Unstable con il rischio di soffrire qualche mal di testa per i bug che saltano fuori ad ogni nuova versione di un programma. Ad ognuno la sua 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. Il team LTS di Debian si occupa degli ultimi (due) anni di supporto per la sicurezza in modo che ogni rilascio benefici di almeno 5 anni di assistenza e che gli utenti possano effettuare l'aggiornamento dalla versione N alla N+2. Per esempio, da Debian 9 Stretch a Debian 11 Bullseye.