Dopo che il tar originale è stato prodotto dal ramo stabilizzato di release, incomincia la parte pubblica del processo di rilascio. Ma prima che il tar sia reso disponibile al mondo diffusamente, dovrebbe essere approvato da un numero minimo di sviluppatori, di solito tre o più. L'approvazione non è una semplice questione di guardare dentro alla release per cercare ovvi errori; idealmente gli sviluppatori scaricano il tar, lo allestiscono e lo installano in un sistema pulito, fanno girare la suite di prova di regressione (vedere sezione chiamata «Testing automatizzato») in Capitolo 8, Gestire i Volontari, e fanno qualche prova manuale. Supponendo che il tar passi i tests, così come ogni altra lista di criteri che può avere il progetto, gli sviluppatori firmano il tar che fa uso di GnuPG (http://www.gnupg.org/), PGP (http://www.pgpi.org/), o di qualche altro programma capace di produrre firme PGP-compatibile.
Nella maggior parte dei progetti, gli sviluppatori appunto usano le loro personali firme digitali, al posto di chiavi di progetto condivise, e possono firmare quanti sviluppatori si vuole (cioè, c'è un numero minimo, ma non un massimo). Più sviluppatori firmano, più tests subisce la release, e anche più grande è la probabilità che un utilizzatore impacciato con la sicurezza possa trovare da sé una percorso di fiducia digitale nei confronti del tar.
Una volta approvata, la release (cioè tutti i tar, i files zip, e tutti gli altri formati con cui viene fatta la distribuzione), dovrebbe essere collocata nell'area di download del progetto, accompagnata dalle firme digitali e dalle somme di controllo MD5/SHA1 (vedere http://en.wikipedia.org/wiki/Cryptographic_hash_function).
Ci sono vari standards per fare ciò. Un modo è accompagnare ciascun pacchetto di release con un file che dia le corrispondenti firme digitali e uno che dia le somme di controllo. Per esempio, se una delle releases impacchettate è la scanley-2.5.0.tar.gz,
sistemate nella stessa directory un file
scanley-2.5.0.tar.gz.asc contenente le firme digitali per il tar, un altro file contenente le sue somme di controllo MD5, e opzionalmente un altro file
scanley-2.5.0.tar.gz.md5 e opzionalmente un altro file
scanley-2.5.0.tar.gz.sha1, contenente la somma di controllo SHA1. Un altro modo di fornire il controllo è quello di riunire tutte le firma digitali per tutti i pacchetti rilasciati in un singolo file, lo
scanley-2.5.0.sigs; lo stesso può essere fatto per le somme di controllo.
In realtà non importa in modo in cui lo facciate. Solo tenetene un semplice schema, descrivetelo chiaramente, e siate coerenti da release in release. Lo scopo di tutto questo firmare digitalmente e di far tutte queste somme di controllo è quello di fornire agli utilizzatori un modo per verificare che la copia che ricevono non sia stata corrotta in modo doloso. Gli utilizzatori sono sul punto di di far girare questo codice sul loro computer se il codice è stato corrotto, uno che vuol fare un attacco può presto avere una posta aperta a tutti i loro dati. Vedere sezione chiamata «Le Releases di Sicurezza» più avanti in questo capitolo per maggiori dettagli sulla paranoia.
Per le releases importanti contenenti molti cambiamenti, molti progetti preferiscono metter fuori le release candidates prima,
cioè, scanley-2.5.0-beta1 prima della
scanley-2.5.0. Lo scopo di una candidate è quello di sottoporre a una estesa fase di testing prima di darle il benelacito di release ufficiale. Se si trovano problemi, essi vengono corretti un ramo di release ed viene esibita una nuova candidate release.
(scanley-2.5.0-beta2). Il ciclo continua finché non sono rimasti più bugs inaccettabili, punto nel quale l'ultima release candidate diventa la release ufficiale, cioè l'unica differenza fra la release candidate e la release reale è la rimozione del qualificatore dal numero di versione.
Sotto moltissimi aspetti, una candidate release deve essere considerata allo stesso modo di una vera release. Il qualificatore alpha, beta, o rc è sufficiente a mettere in guardia gli utilizzatori conservatori dall'aspettare fino alla vera release, e certamente le email di annuncio delle candidate releases dovrebbero mettere in evidenza che il loro scopo è quello di sollecitare reazioni. Tranne questo date alle candidate release la stessa quantità di attenzione che date alle normali release. Dopotutto, voi volete che la gente usi le candidates, a causa della esposizione migliore per scoprire bugs non scoperti, e anche perché voi non sapete mai quale candidate si conclude dando inizio alla release ufficiale.
Annunciare una release è come annunciare ogni altro evento, e dovrebbe usare le procedure descritte in sezione chiamata «La Pubblicità» in Capitolo 6, Comunicazione. Ci sono tuttavia poche nuove cose specifiche da fare.
Ogni volta che date l'URL al tar scaricabile della release, assicuratevi di dare anche la somma di controllo MD5/SHA1 e i puntatori al file delle firma digitali. Poiché gli annunci avvengono in molte tribune (mailing lists, pagine di news, ecc..), ciò significa che gli utilizzatori possono prendere le somme di controllo da molte fonti, il che dà ai titubanti sulla sicurezza una assicurazione extra che le somme di controllo stesse non sono state corrotte. Dare il link al file delle firme digitali molte volte non rende queste firme digitali più sicure, ma rassicura la gente (specialmente quelli che non seguono il progetto da vicino) che il progetto prende la sicurezza seriamente.
Nelle email di annuncio, e sulle pagine di news che contengono più che una semplice fascetta pubblicitaria sulla release, assicuratevi di inserire la porzione rilevante del file CAMBIAMENTI, così la gente può vedere perché dovrebbe essere loro interesse aggiornare. Ciò è importante sia con le candidate releases sia con le releases finali; la presenza di correzioni di bug e di nuove funzionalità è importante nel tentare la gente a provare una candidate release.
Infine, non dimenticate di ringraziare il team di sviluppo, quelli che hanno fatto i tests, e tutti quelli che hanno dedicato tempo ad archiviare buoni report di bugs. Non distinguerteli per nome, comunque, a meno che non ci sia qualcuno responsabile di una grossa parte del lavoro, il valore del quale sia riconosciuto da ognuno nel progetto. Giusto stiate attenti a non scivolar giù con la tendenza scivolosa all'inflazione dei riconoscimenti(vedere sezione chiamata «Riconoscimenti» in Capitolo 8, Gestire i Volontari).