Note di rilascio e cronologia: archivio

Perché conservare una cronologia

Le istruzioni per GNU/Linux invecchiano in modo diseguale. Un concetto come la separazione tra stable, testing e unstable rimane utile a lungo; il nome di un pacchetto, una unit di servizio o una configurazione di rete possono invece cambiare. Conoscere l’epoca di una guida permette di riconoscere i dettagli che richiedono un controllo prima di essere applicati.

Questa pagina riordina alcuni rilasci che segnarono la vita del portale storico. Le date e i nomi sono verificabili nell’indice ufficiale, che resta la fonte da usare per lo stato corrente, la durata del supporto e le note di installazione.

Da Sarge a Jessie

• Debian 3.1 “Sarge”: 6 giugno 2005.
• Debian 4.0 “Etch”: 8 aprile 2007.
• Debian 5.0 “Lenny”: 14 febbraio 2009.
• Debian 6.0 “Squeeze”: 6 febbraio 2011.
• Debian 7 “Wheezy”: 4 maggio 2013.
• Debian 8 “Jessie”: 25 aprile 2015.

Queste tappe spiegano molti termini ancora presenti nei vecchi collegamenti in ingresso: installazioni di Wheezy, passaggi da stable a testing, supporto di Squeeze e arrivo di nuovi ambienti desktop. La cronologia non invita a usare release obsolete; serve a identificare il contesto e a cercare la procedura equivalente per una release supportata.

Stable, testing, unstable ed experimental

Stable è la release pubblicata e consigliata per l’uso di produzione. Testing raccoglie pacchetti destinati alla futura stable dopo il percorso di migrazione; unstable, chiamata sempre “sid”, è il ramo nel quale avviene lo sviluppo attivo. Experimental non è una release completa: viene usata per pacchetti che richiedono ulteriore lavoro o che non sono ancora adatti a unstable.

Il nome in codice di stable cambia a ogni rilascio, mentre le etichette stable e testing si spostano. Per una macchina che deve restare prevedibile, scegliere consapevolmente tra nome in codice ed etichetta è importante: la seconda può condurre al rilascio successivo quando questo diventa stable. Prima di un avanzamento leggere sempre le note ufficiali della release di destinazione.

Point release e supporto

Una point release raccoglie correzioni già distribuite attraverso gli aggiornamenti di una stable; non crea un ramo separato. Un sistema mantenuto correttamente riceve gli stessi aggiornamenti tramite APT. Le immagini di installazione aggiornate riducono soltanto il lavoro necessario subito dopo il primo avvio.

Il ciclo di vita combina il supporto pieno e la fase LTS secondo il calendario ufficiale. Le date non vanno dedotte dal numero di versione né da una vecchia notizia. Per questo l’archivio rimanda alla pagina dei rilasci invece di dichiarare una release “corrente” in un testo destinato a durare.

Come leggere una vecchia procedura

1. Identificare release e data della procedura.
2. Controllare se i pacchetti citati esistono nella propria release.
3. Confrontare file di configurazione e pagina di manuale installata.
4. Provare prima in una macchina virtuale o su dati non unici.
5. Documentare la modifica e una via di ritorno.

Gli annunci storici hanno valore di contesto, ma la documentazione corrente decide l’azione. Questo archivio non replica comunicati, commenti o post attribuiti a utenti: costruisce una linea temporale essenziale usando dati verificati. Una procedura può inoltre contenere un comando ancora valido ma una motivazione superata: entrambi devono essere controllati. Annotare il nome in codice del sistema, la versione del pacchetto interessato e il collegamento alla documentazione consultata rende il confronto ripetibile. Se la guida propone repository o chiavi non più mantenuti, non adattarli per tentativi: cercare il percorso supportato per la release installata. Il confronto termina soltanto quando l’esito è stato verificato sul sistema reale prima di procedere.