Software Veröffentlichungspraktiken HOWTO

 

Autor: Eric Steven Raymond <esr@thyrsus.com>, Thyrsus Enterprises
Übersetzer: Steven Schubiger  

Copyright: Copyright © 2000 Eric S. Raymond  
Source: http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/

Datum - Inhalt: 2002-08-02
Datum - Übersetzung: 2003-12-09

 


    

Überarbeitungs Verlauf
Revision 3.4 2002-01-04 Revidiert durch: esr
Einige Ergänzungen betreffend bewährten Patchingpraktiken
Revision 3.3 2001-08-16 Revidiert durch: esr
Neuer Themenbereich: bewährte Patchingpraktiken
Revision 3.2 2001-07-11 Revidiert durch: esr
Kommentar hinzugefügt, dass man sich nicht auf proprietäre Komponenten verlassen sollte.
Revision 3.1 2001-02-22 Revidiert durch: esr
LDP Styleguide Korrekturen.
Revision 3.0 2000-08-12 Revidiert durch: esr
Erste DocBook Version. Ratschlag betreffend SourceForge; zusätzlich wurde der Themenbereich: "Gute Lizenzierungs- und Urheberrechtpraktiken: die Praxis" hinzugefügt.




Abstrakt

Dieses HOWTO beschreibt bewährte Veröffentlichungspraktiken für Linux und andere Open-Source Projekte. Durch die Durchsetzung dieser Praktiken wird dem Endbenützer die Kompilierung und Verwendung deines Codes vereinfacht; andere Entwickler hingegen werden deinen Code besser verstehen, sodass sie besser kooperieren wie auch die Funktionalität verbessern können.

Dieses Dokument ist praktisch eine Zwangslektüre für unerfahrene Entwickler. Erfahrene Entwickler sollten es jeweils zu Herzen nehmen bevor sie ein neues Projekt veröffentlichen. Es wird periodisch überarbeitet werden, um mit der Evolution von sich bewährenden Standards Schritt zu halten.


Inhalt
1. Einführung
1.1. Zweck dieses Dokumentes?
1.2. Neue Versionen dieses Dokumentes
2. Bewährte Patchingpraktiken
2.1. Sende Patches, keine ganzen Archive oder Dateien
2.2. Sende Patches, die der aktuellen Version des Codes angepasst sind.
2.3. Inkludiere keine Patches für generierte Dateien.
2.4. Sende keine Patchbänder, die nur die RCS oder SCCS $-Symbole verändern.
2.5. Gebrauche -c oder -u format, und nicht den Standard Parameter (-e) format
2.6. Versehe deinen Patch mit einer Dokumentation
2.7. Versehe deinen Patch mit einer Erläuterung
2.8. Versehe deinen Code mit nützlichen Kommentaren
3. Bewährte Projekt- und Archiv- Namensvergabe Praktiken
3.1. Gebrauche GNU-konforme Dateinamen mit einer Basis und einer major.minor.Patch Nummerierung.
3.2. Aber respektiere lokale Konventionen wo sie als angemessen erscheinen
3.3. Wähle ein einzigartes Namenspräfix, welches einfach zu tippen ist
4. Gute Lizenzierungs- und Urheberrechtpraktiken: die Theorie
4.1. Open Source und Urheberrechte
4.2. Was als Open Source qualifiziert werden kann
5. Gute Lizenzierungs- und Urheberrechtpraktiken: die Praxis
5.1. Benenne dich oder die Free Software Foundation als Urheber
5.2. Verwende eine Lizenz, die zu der Open Source Definition konform ist
5.3. Schreibe keine eigene Lizenz, sofern es vermieden werden kann
6. Löbliche Entwicklungspraktiken
6.1. Schreibe entweder pures ANSI C oder in einer portablen Scriptsprache
6.2. Verlass dich nicht auf proprietären Code
6.3. Befolge die C Portabilitätspraktiken
6.4. Gebrauche autoconf/automake/autoheader
6.5. Überprüfe deinen Code bevor du ihn veröffentlichst
6.6. Überprüfe deine Dokumentation und READMEs vor einer Veröffentlichung
7. Die richtige Kreierung einer Distribution
7.1. Stelle sicher, dass tarballs sich immer in ein eigenes neues Verzeichnis entpacken
7.2. Füge ein README hinzu
7.3. Respektiere und befolge Standard Namensvergabepraktiken
7.4. Entwerfe für Erneuerbarkeit
7.5. Stelle RPMs zur Verfügung
8. Bewährte Dokumentationspraktiken
8.1. Bewährte Praktiken in der Gegenwart
8.2. Sich bewährende Praktiken für die Zukunft
9. Bewährte Kommunikationspraktiken
9.1. Kündige es unter c.o.l.a und Freshmeat an
9.2. Kündige es in einer themenrelevanten Newsgruppe an
9.3. Kreiere eine Website
9.4. Stelle Projekt Mailinglisten bereit
9.5. Veröffentliche es in wichtigen Archiven
10. Gute Projektmanagement Praktiken