Versioni, cicli di rilascio e nomi in codice

Quattro nomi, funzioni diverse

Stable è la distribuzione pubblicata e orientata alla prevedibilità. Testing contiene i pacchetti che hanno superato condizioni di migrazione e prepara la prossima stable. Unstable è il ramo di sviluppo attivo e conserva il nome “sid”. Experimental ospita singoli pacchetti o cambiamenti che richiedono ulteriore lavoro e non costituisce un sistema completo da scegliere come release.

La pagina ufficiale dei rilasci Debian descrive lo stato corrente e il ciclo di vita. Consultarla prima di installare o avanzare evita di affidarsi a una tabella copiata anni prima.

Etichetta mobile o nome in codice

Una sorgente che usa stable segue ciò che il progetto indica come stable. Quando avviene un nuovo rilascio, il significato dell’etichetta cambia. Una sorgente che usa un nome in codice resta invece legata a quella specifica distribuzione. Entrambe le scelte sono legittime, ma producono comportamenti diversi nel giorno del rilascio.

Su sistemi che devono avanzare solo dopo una decisione esplicita, il nome in codice rende più visibile il passaggio. Su una macchina di laboratorio si può preferire seguire un ramo mobile. In entrambi i casi, non sostituire alla cieca una parola nei file APT: leggere le note di rilascio e verificare archivi aggiuntivi, spazio e servizi critici.

Come i pacchetti raggiungono testing

I pacchetti entrano prima in unstable e migrano verso testing quando soddisfano le condizioni del processo. Testing non significa che ogni pacchetto sia stato collaudato come parte di una release finale; descrive la posizione nel flusso. Durante il freeze le regole diventano più restrittive per preparare il rilascio.

Per chi amministra una workstation, questo spiega perché un pacchetto può essere più recente in unstable, apparire dopo in testing e arrivare infine in stable. Mescolare rami per ottenere un singolo programma trasferisce al gestore del sistema l’onere di risolvere combinazioni che la release non ha scelto.

Point release e aggiornamenti

Le point release aggiornano il supporto di installazione e consolidano correzioni già distribuite. Non richiedono una reinstallazione a chi mantiene la stable aggiornata con APT. Il numero dopo il punto è utile per identificare un supporto o un’immagine, ma non crea un ramo separato.

Gli aggiornamenti di sicurezza seguono i canali previsti dalla release e vanno applicati con regolarità. La presenza di una nuova point release è un buon momento per verificare che gli aggiornamenti automatici o manuali funzionino, non per attendere prima di correggere un problema già pubblicato.

Supporto pieno, LTS e archivi storici

Il ciclo ufficiale distingue il periodo di supporto pieno dalla fase Long Term Support. Le date sono pubblicate per ogni release e possono variare nei dettagli: non dedurle da una regola mnemonica. Quando una distribuzione termina il supporto, i pacchetti possono spostarsi verso archivi storici che non trasformano però il sistema in una piattaforma sicura per l’uso ordinario.

Pianificare l’avanzamento prima della scadenza permette di collaudare applicazioni e backup. Una macchina virtuale con copia dei dati non sensibili è utile per verificare configurazioni, ma il test decisivo resta l’applicazione reale con le sue dipendenze e i suoi flussi.

Piano minimo per un avanzamento

1. Leggere note di rilascio e problemi noti.
2. Verificare una copia ripristinabile dei dati.
3. Rimuovere o disabilitare temporaneamente archivi non ufficiali dopo averne annotato lo scopo.
4. Portare la release attuale allo stato previsto dalle note.
5. Eseguire l’avanzamento da una console recuperabile.
6. Controllare servizi falliti, rete, spazio e log.

Un avanzamento è un progetto di manutenzione, non una singola riga di comando. Documentare l’esito rende la procedura ripetibile sulle altre macchine e aiuta a distinguere una regressione da un vecchio problema già presente.