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.