Il codice sorgente dovrebbe essere inviato in formati standard per trasportare alberi di directory. Per i sistemi operativi Unix e pseudo Unix, la convenzione è usare il formato TAR, compresso da compress, gzip, bzip o bzip2 che sembra fare la compressione anche bene, in modo che non c'è bisogno di comprimere l'archivio dopo averlo creato.

Il nome del pacchetto dovrebbe consistere nel nome del software, più il numero di release, più il suffisso di formato per il tipo di archivio. Per esempio, Scanley 2.5.0, impacchettato per Unix che usa la compressione GNU Zip (gzip), apparirebbe come questo:

o per Windows che usa la compressione zip:

Ciascuno di questi archivi, quando è estratto, dovrebbe creare un unico albero di directory chiamato scanley-2.5.0 nella directory corrente. Sotto la nuova directory, il codice sorgente dovrebbe essere sistemato in una disposizione pronta per la compilazione (se c'è bisogno di compilazione) e per l'installazione. Nel livello più alto dell'albero delle directory ci dovrebbe essere un file di testo piano README che spieghi ciò che il software fa e quale release è, e che dà le indicazioni per altre risorse, come il sito del progetto, altri file di interesse, ecc.. Fra questi altri files ci dovrebbe essere un file fratello INSTALL del file README che dia istruzione su come costruire e installare il software per tutti i sistemi operativi che supporta. Come menzionato in sezione chiamata «Come Applicare Una Licenza Al Vostro Software» in Capitolo 2, Partenza, ci dovrebbe essere anche un file COPYING or LICENSE che fornisca i termini di distribuzione.

Ci dovrebbe essere anche un file CHANGES (a volte chiamato NEWS), che spieghi ciò che c'è di nuovo in quella release. Il file CHANGES accumula le liste dei cambiamenti per tutte le releases, in ordine cronologico inverso, in modo che la lista per quella release appaia in cima al file. A completare la lista c'è usualmente l'ultima cosa fatta per stabilizzare il ramo di release; alcuni progetti scrivono la lista un pò alla volta mentre si sviluppano, altri preferiscono salvarla alla fine di tutto, e hanno una persona a scriverla, che prende le informazioni setacciando i log del controllo di versione. La lista appare come qualcosa del genere:

Version 2.5.0
(20 December 2004, da /rami/2.5.x)
http://svn.scanley.org/repos/svn/tags/2.5.0/

 New features, enhancements:
    * Added regular expression queries (issue #53)
    * Added support for UTF-8 and UTF-16 documents
    * Documentation translated into Polish, Russian, Malagasy
    * ...

 Bugfixes:
    * fixed reindexing bug (issue #945)
    * fixed some query bugs (issues #815, #1007, #1008)
    * ...

L'elenco può facilmente essere tanto lungo quanto è necessario, ma non vi preoccupate di includere ogni piccola correzione di bug e accrescimento di funzionalità. Il suo proposito è solamente dare agli utilizzatori una visione d'insieme di quale sarebbe il guadagno ad aggiornare alla nuova release. Infatti, la lista dei cambiamenti è abitualmente inclusa nelle email di annuncio (vedere sezione chiamata «Prove e Rilascio» più avanti in questo capitolo), in modo che la scriviate con il pubblico nella mente.

Usualmente ci sono poche differenze, per esempio perché il pacchetto contiene alcuni file generati necessari per la compilazione e la configurazione (vedere sezione chiamata «Compilazione e Installazione» più avanti in questo capitolo), o perché contiene un software di terze parti di cui il progetto non fa manutenzione, ma ciò è richiesto e ciò è probabile che gli utilizzatori non abbiano. Ma anche se l'albero distribuito corrispondesse esattamente ad alcuni alberi di sviluppo nel deposito del controllo di versione, la distribuzione stessa non sarebbe un copia funzionante (vedere copia di lavoro). Si suppone che la release un punto di riferimento statico una particolare, immutabile configurazione dei files sorgenti. Se essa fosse una copia funzionante, il danno sarebbe che gli utilizzatori potrebbero aggiornarla, e successivamente pensare di avere ancora la release quando nei fatti egli ha qualcosa di differente.

Ricordate che il pacchetto è lo stesso indipendentemente dalla confezione. La release cioè la precisa entità riferita a quando qualcuno dice "Scanley 2.5.0"—è l'albero creato estraendo un file zip o tar. Così il progetto potrebbe offrire tutti questi per il download:

...ma l'albero sorgente estraendoli deve essere lo stesso. Quell'albero sorgente è la distribuzione.; la forma in cui è scaricato è un pura questione di convenienza. Certe differenze secondarie fra i pacchetti sorgente sono ammissibili: per esempio, nel pacchetto Windows i file di testo devono avere un fine linea con CRLF (Carriage Return and Line Feed), mentre il pacchetto Unix deve usare giusto LF. Gli alberi possono essere sistemati in maniera poco differente fra i pacchetti destinati a sistemi operativi differenti, anche, se questi sistemi operativi richiedono diversi tipi sistemazione per la compilazione. Comunque, queste sono di base le tutte le trasformazioni secondarie. I file sorgenti di base devono essere gli stessi nell'impacchettamento di una data release.

Per software che richiede compilazione e installazione dal sorgente, si sono usualmente delle procedure standard che si presume gli utilizzatoti esperti siano capaci di seguire. Per esempio, per programmi scritti in C, C++, o certi altri linguaggi compilati, lo standard per sistemi tipo Unix e che l'utilizzatore batta:

   $ ./configure
   $ make
   # make install

Il primo comando individua come sa l'ambiente e prepara il processo di allestimento (ma non installa), e il secondo comando installa sul sistema. I primi due comandi sono impartiti come utente normale, il terzo come radice. Per maggiori dettagli su come settare il sistema, vedere l'eccellente libro GNU Autoconf, Automake, and Libtool di Vaughan, Elliston, Tromey, e Taylor. Esso è pubblicato su carta da New Riders, e il suo contenuto è anche disponibile in forma freeware online a http://sources.redhat.com/autobook/.

Questo non è il solo standard, sebbene sia uno dei più diffusi. Il sistema di allestimento Ant (http://ant.apache.org/) sta guadagnando popolarità, specialmente con progetti scritti in Java, ed ha le sue proprie procedure standard per l'allestimento e l'installazione. Inoltre, certi linguaggi di programmazione come Perù e Pathos, raccomandano che, per la maggioranza del programmi scritti in quel linguaggio sia usato lo stesso metodo (per esempio moduli Perl usano il comando perl Makefile.PL). Se non è ovvio per voi quale debba essere lo standard applicabile per il vostro progetto, chiedete a uno sviluppatore esperto; potete con sicurezza accettare che qualche standard si applica, anche se non sapete quale venga prima.

Quale che sia lo standard adatto per il vostro progetto, non deviate da esso a meno che non dobbiate certamente farlo. Le procedure standard per l'installazione sono in pratica dei responsi automatici a stimoli specifici per un sacco di amministratori di sistema attualmente. Se essi vedono richieste di aiuto be note documentate nel file, ciò istantaneamente genera in essi la credenza che il vostro progetto è generalmente fuori dalle convenzioni, e anche che sarebbe riuscito bene in altre cose. Anche, come discusso in sezione chiamata «Downloads» in Capitolo 2, Partenza, avere una procedura standard di allestimento piace ai potenziali sviluppatori.

Su Windows gli standards per l'allestimento e per l'installazione sono un po' meno fissi. Per progetti che richiedono la compilazione, la convenzione generale sembra essere inviare un albero che si può sistemare in un modello di area di lavoro/progetto dell'ambiente di sviluppo standard di Microsoft (Developer Studio, Visual Studio, VS.NET, MSVC++, ecc...). A seconda della natura del vostro software, può essere possibile offrire una opzione di allestimento su Windows via ambiente Cygwin. (http://www.cygwin.com/) E certamente, se state usando un linguaggio o un framework di programmazione che viene con le sue convenzioni di allestimento e installazione, per esempio Phiton o Perl dovreste semplicemente usare quello che sia il metodo standard per quel framework, su Windows, Unix, Mac OS X, o ogni altro sistema operativo.

Siate disponibili a metterci un sacco di impegno extra per rendere il vostro progetto conforme agli standards di rilievo per l'allestimento e l'installazione. L'allestimento e l'installazione sono una fase di ingresso: è giusto che le cose diventino più difficili dopo di essi, se è fuori discussione che lo siano, ma sarebbe un disonore nei confronti degli utilizzatori o degli sviluppatori se la prima interazione col software richiedesse passi imprevisti.

Sebbene la release formale sia un pacchetto di codice sorgente, la maggior parte degli utilizzatori installeranno da pacchetti binari, sia che siano forniti dal meccanismo di distribuzione del software del sistema operativo, sia che siano ottenuti manualmente dal sito del progetto o da terze parti. Qui “binario” non significa necessariamente “compilato”; significa giusto una forma pre-configurata del pacchetto che permette a un utilizzatore di installarla sul proprio computer senza passare attraverso le solite procedure di allestimento e installazione. Su RedHat GNU/Linux, è il sistema RPM; su Debian GNU/Linux, È il sistema APT (.deb); su Windows, di solito i files .MSI il file autoistallante .exe.

Se il file binario sia assemblato da gente strettamente associate al progetto, o da distanti terze parti, gli utilizzatori tendono a considerarli equivalenti alle releases ufficiali del progetto, e depositeranno i problemi nel tracciatore di bug apposito per il comportamento dei pacchetti binari. Quindi, è nell'interesse del progetto fornire pacchetti con chiare linee guida, e lavorare moltissimo con esse per assicurarsi che quello che producono rappresenti il software in modo pulito e accurato.

La cosa principale che gli impacchettatori hanno bisogno di sapere è che essi dovrebbero basare sempre i loro pacchetti binari su una release ufficiale originale. Talvolta gli impacchettatori son tentati di tirar fuori una recente incarnazione del codice dal deposito, o di includervi cambiamenti selezionati che furono inviati dopo che la release fu fatta, per fornirli agli utilizzatori con certe correzioni di bugs o altri miglioramenti. Chi fa i pacchetti pensa di star facendo un favore ai suoi utilizzatori nel dare loro codice più recente, ma in realtà questa pratica causa una gran quantità di confusione. I progetti sono preparati a ricevere rapporti di bugs trovati nelle versioni rilasciate, e di bugs trovati nel recente tronco e nel codice del ramo maggiore (cioè trovati da gente lì apposta per far girare codice a rischio di stabilità e produttività). Quando un bug proviene da queste fonti, il risponditore sarà spesso capace di confermare che è noto che quel bug è presente in quell'istantanea, e forse che da allora è stato corretto e che l'utente dovrebbe aggiornare o aspettare la successiva release. Se esso è un precedente bug non noto, l'avere l'esatta release fa si che sia più facile riprodurlo e più facile classificarlo nel tracciatore.

progetti non sono preparati, comunque, a ricevere rapporti di bugs basati su un mezzo intermedio non specifico o su versioni ibride. Tali bugs possono essere difficili da riprodurre; inoltre possono essere dovuti a interazioni non previste in cambiamenti isolati introdotti da successivi sviluppi, quindi causano cattivi comportamenti di cui gli sviluppatori del progetto non dovrebbero essere incolpati. Ho visto una sconcertante gran quantità di tempo sprecata perché un bug era absent quando avrebbe dovuto essere presente: qualcuno stava facendo girare una versione leggermente modificata, basata (ma non identica) su una release ufficiale, e quando i bug predetto non si verificava ognuno doveva scavare un fossato per capire il perché.

Tuttavia quelle erano circostanze in cui chi faceva il pacchetto insisteva sul fatto che quelle modifiche alla release originale erano necessarie. Chi faceva i pacchetti avrebbe dovuto essere incoraggiato a tirar fuori questo con gli sviluppatori del progetto e a spiegare i suoi piani. Essi possono trovare consenso, ma mancando questo, almeno avranno notificato al progetto le loro intenzioni, così che il progetto può stare attento a insoliti rapporti di bugs. Gli sviluppatori possono rispondere mettendo un disclaimer sul sito del progetto, e possono chiedere a chi fa i pacchetti di fare la stessa cosa nel posto appropriato, di modo che gli utilizzatori di quel pacchetto binario sappiano che ciò che stanno prendendo non è esattamente la stessa cosa di ciò che il progetto ha rilasciato. Non ci deve essere animosità in questa situazione, sebbene purtroppo spesso ce ne sia. E' solo che chi fa i pacchetti ha degli obiettivi leggermente differenti da quelli degli sviluppatori. Coloro che fanno i pacchetti vogliono che i loro utilizzatori incontrino le migliori funzionalità. Gli sviluppatori vogliono anche questo, certo, ma hanno anche bisogno di essere sicuri di conoscere quali versioni del software ci sono in giro, in modo da poter ricevere rapporti di bugs intellegibili e garantire compatibilità. A volte i loro obiettivi sono in conflitto. Quando ciò avviene è bene avere in mente il fatto che il progetto non ha nessun controllo su coloro che fanno i pacchetti e che i vincoli degli obblighi funzionano in entrambe le direzioni. E' vero che il progetto sta facendo un favore a chi fa i pacchetti semplicemente producendo il software. Ma anche quelli che fanno i pacchetti stanno facendo un favore al progetto e si stanno accollando un lavoro non eccitante per rendere il software più largamente disponibile, spesso per ordine di rilievo. E' bene non essere d'accordo con gli impacchettatori, ma non è bene offenderli. Giusto cercate una soluzione alle cose meglio che potete.