La maggior parte dei progetti maturi fanno la manutenzione a pi� di una linea di release in parallelo. Per esempio, dopo che vien fuori la 1.0.0, quella linea dovrebbe continuare con le micro releases (di correzione bugs) 1.0.1, 1.0.2, ecc. Notare che il solo rilascio della 1.1.0 non � una ragione sufficiente per terminare la linea 1.0.x. Per esempio, alcuni utilizzatori hanno l'abitudine di non aggiornare mai alla prima release in una serie minore o maggiore—lasciano gli altri a rimuovere i bugs, per esempio dalla 1.1.0, e aspettano fino alla 1.1.1. Ci� non � necessariamente egoista (ricordate che essi stanno rinunciando alle correzioni di bugs e anche a nuove funzionalit�); � solo che, per una qualsiasi ragione, hanno deciso di essere molto prudenti con gli aggiornamenti. Di conseguenza, se il progetto viene a conoscenza di un bug importante nella 1.0.3 giusto prima che stia rilasciando la 1.0.3, dovrebbe essere un p� rigido nel mettere appunto la correzione del bug nella 1.1.0 e a dire a tutti i vecchi utilizzatori della 1.0.x che dovrebbero aggiornare. Perch� non rilasciare sia la 1.1.0 che la 1.0.4, in modo che ognuno sia felice?
Dopo che la linea 1.1.x � in cammino, potete dichiarare che la 1.0.x � alla fine della vita. Questo dovrebbe essere annunciato ufficialmente. L'annuncio dovrebbe essere unico, o dovrebbe essere menzionato come parte dell'annuncio della release 1.1.x; comunque fatelo, gli utilizzatori hanno bisogno di sapere che la vecchia linea sta venendo gradualmente eliminata, cos� che di conseguenza possano prendere la decisione di aggiornare.
Alcuni progetti stabiliscono un intervallo di tempo durante il quale si impegnano a supportare la linea di release precedente. In un contesto open source “supportare” significa accettare i reports di bugs su quella linea e creare release di manutenzione quando vengono trovati bugs significativi. Altri progetti non vi dedicano una quantit� di tempo definita, ma tengono d'occhio i reports di bugs che arrivano per misurare quanta gente sta usando la vecchia linea. Quando la percentuale scende sotto un certo livello essi dichiarano la fine della vita per quella linea e smettono di supportarla.
Per ogni release assicuratevi di avere una versione obiettivo o una pietra miliare obiettivo nel tracciatore di bug, cos� la gente che archivia i bugs sapr� fare cos� nei confronti della propria release. Non dimenticate nemmeno di avere un obiettivo “sviluppo” o “ultimo” per le pi� recenti fonti di sviluppo, poich� alcune persone non solo sviluppatori attivi rimangano avanti rispetto alla release ufficiale.
La maggior parte dei dettagli sulla gestione dei bug sulla sicurezza era trattata in sezione chiamata �Annunciare le Vulnerabilit� della Sicurezza� in Capitolo�6, Comunicazione, ma l� ci sono dettagli specifici per creare releases di sicurezza.
Una release di sicurezza � una release fatta solo per chiudere falle nella sicurezza. Il codice che corregge i bugs non pu� essere reso pubblico finch� la release non � disponibile, il che significa non solo che i bugs non possono essere inviati al deposito fino al giorno della release, ma anche che la release non pu� essere testata pubblicamente prima che esca. Ovviamente gli sviluppatori possono esaminare i bugs fra di loro, e testare la release in privato, ma la diffusione nel mondo del testing reale non � possibile.
A causa di questa mancanza di testing, una release sulla sicurezza dovrebbe sempre essere fatta di alcune releases esistenti pi� le correzioni dei bugs di sicurezza, con nessun altro cambiamento. Questo perch� pi� cambiamenti inviate senza testing, pi� probabilmente quell'unico fra essi causer� un nuovo bug, forse un nuovo bug di sicurezza. La prudenza � anche di famiglia per gli amministratori che possono aver bisogno di aprire le correzioni sulla sicurezza, ma la cui politica di aggiornamento preferisce di non aprire nessun altro cambiamento nello stesso tempo.
Il creare una release di sicurezza a volte comporta qualche inganno minore. Per esempio il progetto pu� aver lavorato alla release 1.1.3, con certe correzioni di bugs gi� pubblicamente dichiarate, quando arriva un report di bugs. Naturalmente gli sviluppatori non possono parlare di problemi si sicurezza fino a quando non rendono disponibile la correzione. Fino ad allora essi devono continuare a parlare pubblicamente come se la 1.1.3 sar� ci� che si � sempre pianificato che sia. Ma quando la 1.1.3 finalmente esce, differir� dalla 1.1.2 solo per le correzioni dei bugs sulla sicurezza, e tutte le altre correzioni saranno state rinviate alla 1.1.4 (che certamente ora conterr� anche le correzioni sulla sicurezza, come le conterranno tutte le releases future).
Potreste aggiungere un componente extra in una release esistente per indicare che essa contiene solo cambiamenti sulla sicurezza. Per esempio la gente dovrebbe saper dire, giusto dai numeri che la 1.1.2.1 � una release di sicurezza nei confronti della 1.1.2 e dovrebbero sapere che ogni release pi� “alta” di quella (per esempio, 1.1.3, 1.2.0, ecc...) contiene le stesse correzioni sula sicurezza. Per quelli ben informati, questo sistema porta un sacco di informazioni. D'altra parte, per quelli che non seguono il progetto da vicino, pu� essere causa di confusione vedere un numero di release a tre componenti la maggior parte delle volte con una release a quattro componenti inserita apparentemente a caso. La maggior parte dei progetti che ho visto scelgono la coerenza e semplicemente e scelgono il numero successivo regolarmente programmato per le releases di sicurezza, anche quando ci� significa far slittare di uno le altre releases programmate.