Avanti Indietro Indice

Software Release Practice HOWTO

Eric S. Raymond <esr@thyrsus.com>

1.0, 21 novembre 1998

Questo HOWTO descrive le regole di una buona release per un progetto open-source per Linux. Seguendo queste regole, si faciliterà il più possibile gli utenti nel costruire il codice e usarlo, e gli altri sviluppatori nel capirlo e cooperare per migliorarlo. Questo documento è una lettura obbligata per i novelli sviluppatori. Gli sviluppatori esperti devono fare una revisione quando stanno rilasciando un nuovo progetto. Verrà riveduto periodicamente per mostrare le evoluzioni degli standard. La traduzione italiana è stata curata da Edoardo Rampazzo <Taedium@mclink.it>

1. Introduzione

1.1 Perché questo documento?
1.2 Nuove versioni di questo documento

2. Buone regole per dare un nome a un progetto e a un archivio

2.1 Usare nomi nello stile GNU, con una radice e numerazione delle patch primarie.secondarie
2.2 Scegliere con accuratezza un nome per il prefisso che sia unico e facile da digitare

3. Buone regole di sviluppo

3.1 Scrivere in puro ANSI C o in un linguaggio portabile
3.2 Seguire le buone regole della portabilità del linguaggio C
3.3 Utilizzare autoconf/ automake/ autoheader
3.4 Controllare lo stato del codice prima di rilasciarlo

4. Buone regole per creare una distribuzione

4.1 Essere sicuri che gli archivi tar vengano sempre decompressi in una nuova singola directory
4.2 Fornire un README
4.3 Rispettare e seguire le regole standard per la titolazione dei file

5. Buone regole di comunicazione

5.1 Riferire a c.o.l.a
5.2 Riferire ad un newsgroup attinente al tema
5.3 Fornire un sito Web
5.4 Creare delle mailing list attinenti al progetto
5.5 Distribuzione attraverso i più importanti archivi
5.6 Fornire archivi RPM

Avanti Indietro Indice