<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <TITLE>Software Release Practice HOWTO</TITLE> <LINK HREF="Software-Release-Practice-HOWTO-1.html" REL=next> </HEAD> <BODY> <A HREF="Software-Release-Practice-HOWTO-1.html">Avanti</A> Indietro Indice <HR> <H1>Software Release Practice HOWTO</H1> <H2>Eric S. Raymond <esr@thyrsus.com></H2>1.0, 21 novembre 1998 <P><HR> <EM>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></EM> <HR> <P> <H2><A NAME="toc1">1.</A> <A HREF="Software-Release-Practice-HOWTO-1.html">Introduzione</A></H2> <UL> <LI><A HREF="Software-Release-Practice-HOWTO-1.html#ss1.1">1.1 Perché questo documento?</A> <LI><A HREF="Software-Release-Practice-HOWTO-1.html#ss1.2">1.2 Nuove versioni di questo documento</A> </UL> <P> <H2><A NAME="toc2">2.</A> <A HREF="Software-Release-Practice-HOWTO-2.html">Buone regole per dare un nome a un progetto e a un archivio</A></H2> <UL> <LI><A HREF="Software-Release-Practice-HOWTO-2.html#ss2.1">2.1 Usare nomi nello stile GNU, con una radice e numerazione delle patch primarie.secondarie</A> <LI><A HREF="Software-Release-Practice-HOWTO-2.html#ss2.2">2.2 Scegliere con accuratezza un nome per il prefisso che sia unico e facile da digitare</A> </UL> <P> <H2><A NAME="toc3">3.</A> <A HREF="Software-Release-Practice-HOWTO-3.html">Buone regole di sviluppo</A></H2> <UL> <LI><A HREF="Software-Release-Practice-HOWTO-3.html#ss3.1">3.1 Scrivere in puro ANSI C o in un linguaggio portabile</A> <LI><A HREF="Software-Release-Practice-HOWTO-3.html#ss3.2">3.2 Seguire le buone regole della portabilità del linguaggio C</A> <LI><A HREF="Software-Release-Practice-HOWTO-3.html#ss3.3">3.3 Utilizzare autoconf/ automake/ autoheader</A> <LI><A HREF="Software-Release-Practice-HOWTO-3.html#ss3.4">3.4 Controllare lo stato del codice prima di rilasciarlo</A> </UL> <P> <H2><A NAME="toc4">4.</A> <A HREF="Software-Release-Practice-HOWTO-4.html">Buone regole per creare una distribuzione</A></H2> <UL> <LI><A HREF="Software-Release-Practice-HOWTO-4.html#ss4.1">4.1 Essere sicuri che gli archivi tar vengano sempre decompressi in una nuova singola directory</A> <LI><A HREF="Software-Release-Practice-HOWTO-4.html#ss4.2">4.2 Fornire un README</A> <LI><A HREF="Software-Release-Practice-HOWTO-4.html#ss4.3">4.3 Rispettare e seguire le regole standard per la titolazione dei file</A> </UL> <P> <H2><A NAME="toc5">5.</A> <A HREF="Software-Release-Practice-HOWTO-5.html">Buone regole di comunicazione</A></H2> <UL> <LI><A HREF="Software-Release-Practice-HOWTO-5.html#ss5.1">5.1 Riferire a c.o.l.a</A> <LI><A HREF="Software-Release-Practice-HOWTO-5.html#ss5.2">5.2 Riferire ad un newsgroup attinente al tema</A> <LI><A HREF="Software-Release-Practice-HOWTO-5.html#ss5.3">5.3 Fornire un sito Web</A> <LI><A HREF="Software-Release-Practice-HOWTO-5.html#ss5.4">5.4 Creare delle mailing list attinenti al progetto</A> <LI><A HREF="Software-Release-Practice-HOWTO-5.html#ss5.5">5.5 Distribuzione attraverso i più importanti archivi</A> <LI><A HREF="Software-Release-Practice-HOWTO-5.html#ss5.6">5.6 Fornire archivi RPM</A> </UL> <HR> <A HREF="Software-Release-Practice-HOWTO-1.html">Avanti</A> Indietro Indice </BODY> </HTML>
