IMHO, se solo potessi fare una cosa prima di distribuire il tuo progetto (direttamente o indirettamente), ti consiglio di raddoppiare e triplicare per verificare che si compili così com'è dal controllo del codice sorgente.
Non ridere, ma non posso dirti quante volte ho ottenuto "l'ultima" da un controllo sorgente e non è riuscito a compilare, solo per scoprire più tardi che non ero "sulla vecchia scatola di Fred" perché apparentemente il il codice "compila solo sulla vecchia scatola di Fred". Ho persino avuto un ex datore di lavoro che rimuoveva prontamente il mio desktop dal mio cubo e lo sostituivo con "la vecchia scatola di Fred" in modo da poter lavorare sul progetto che dovevo.
Come un'estensione della raccomandazione di cui sopra, perché a volte ottenere l'ultima volta non è tutto ciò che è necessario per compilare un'applicazione, ti consiglio di creare un README.txt e metterlo nella directory root della tua applicazione e metterlo in controllo della fonte. Questo documento README dovrebbe contenere un elenco di dipendenze esterne che non possono essere verificate nel controllo del codice sorgente (se esiste), come configurare il database e qualsiasi altra stranezza sulla compilazione, sull'esecuzione o sui cicli di distribuzione dell'applicazione.
Qualunque cosa al di sopra e al di là dei due suggerimenti precedenti sarebbe solo un piacere, ma IMHO i due precedenti sono quasi obbligatori su qualsiasi progetto più grande di "Hello World".
Modifica
Sull'argomento della documentazione ...
Nel corso degli anni ho scritto e letto la mia buona parte della documentazione del software allo scopo di facilitare la transizione di uno sviluppatore. Direi che questi documenti raramente valgono la carta su cui sono stampati. Gli sviluppatori (me compreso) raramente pensano alle parti importanti dell'applicazione mentre scrivono tali documenti, tendiamo solo a pensare agli incendi più recenti che abbiamo combattuto. Al di là e al di là del fatto che questi documenti tendono a non coprire tutti gli aspetti importanti del software, anche questi diventano obsoleti MOLTO rapidamente. Una volta che il documento è scaduto, è probabile che un futuro sviluppatore lo trascuri completamente, invece di rimetterlo in funzione per corrispondere alla realtà (pensa ai requisiti in evoluzione).
Invece della documentazione di per sé, consiglio i test unitari. So che probabilmente suona vecchio a questo punto, ma lascia che il codice faccia la documentazione per te. I test di unità rotti sono difficili da ignorare (e più facili da individuare) rispetto a un documento di Word. Inoltre, la lingua inglese è orribilmente imprecisa per articolare i punti più importanti del design del software. Ci sono semplicemente troppi modi per interpretare il significato anche delle frasi più semplici in inglese, e questo porta solo a confusione e / o bug.