Der Quellcode sollte in den Standardformaten für die Übertragung von Verzeichnissen verteilt werden. Bei Unix und Unix-ähnlichen Betriebssystemen, ist die Konvention, das TAR Format zu benutzen, komprimiert mit compress, gzip, bzip oder bzip2. Bei MS Windows, ist die Standard-Methode für die Veröffentlichung von Verzeichnissen das zip Format, welches zufällig auch komprimiert, also gibt es keinen Grund es zu komprimieren, nach der Erstellung.

Der Name des Pakets sollte aus dem Namen der Software bestehen, gefolgt von der Versionsnummer und den Dateiendungen für die entsprechenden Archiv typen. Scanley 2.5.0, als Paket für Unix mit der GNU Zip (gzip) Kompression, würde zum Beispiel so aussehen:

oder für Windows mit zip Kompression:

Beide dieser Archive erzeugen, wenn man sie entpackt, eine einziges neues Verzeichnis namens scanley-2.5.0 in dem derzeitigen Ordner. Im neuen Verzeichnis, sollten die Dateien des Quellcodes so ausgelegt sein, welches für die Kompilierung (wenn die Kompilierung nötig ist) und installation bereit ist. In der obersten Verzeichnisebene, sollte es eine Klartext-Datei mit dem Namen README geben, welches erklärt, was die Software macht, was diese Paket ist, und hinweise Auf andere Ressourcen, wie die Webseite des Projekts, andere Dateien die von Interesse sind, usw. Unter diesen anderen Dateien sollte eine INSTALL Datei sein, welches Anweisungen gibt, wie man einen Build der Software machen kann, und sie installieren kann, für alle Betriebssysteme die es unterstützt. Wie in „Eine Lizenz für Ihre Software“ im Kapitel Kapitel 2, Der Einstieg erwähnt, sollte es auch eine COPYING oder LICENSE Datei geben, welche die Bedingungen enthält, unter denen die Software vertrieben werden kann.

Es sollte auch eine CHANGES-Datei geben (manchmal NEWS) genannt, welches erklärt, was in dieser Version neu ist. Die CHANGES-Datei listet die Änderungen aller Versionen auf, in antichronologischer Richtung, sodass die Liste für diese Version in der Datei oben erscheint. Diese Liste zu vervollständigen, ist üblicherweise das Letzte, was auf einem stabilisierenden Versionszweig gemacht wird; manche Projekte schreiben diese Liste in Stücken während sie entwickeln, andere bevorzugen es, alles bis zum Schluss aufzusparen, und es dann von einer Person schreiben zu lassen, indem Informationen aus den Commit-Kommentaren der Versionsverwaltung gesammelt werden. Die Liste sieht in etwa so aus:

Version 2.5.0
(20 Dezember 2004, von /branches/2.5.x)
http://svn.scanley.org/repos/svn/tags/2.5.0/

 Neue Funktionen, Erweiterungen:
    * Neue Abfragen mit regulären Ausdrücken (Meldung #53)
    * Unterstützung für UTF-8- und UTF-16-Dokumente 
    * Documentation in Polnisch, Russisch, Malaysisch
    * ...

 Bugfixes:
    * Bugs in Neuindexierung behoben (Meldung #945)
    * Einige Abfragefehler behoben (Meldung #815, #1007, #1008)
    * ...

Die Liste kann so lang wie nötig sein, Sie brauchen sich aber nicht darum zu kümmern, dass jeder kleiner Bugfix und jede kleine Funktioserweiterung aufgelistet wird. Ihr Sinn ist es einfach, den Nutzern einen Überblick zu geben, inwiefern sie davon profitieren würden, auf die neue Version zu aktualisieren. Die Änderungsliste wird üblicherweise in der Ankündigungs-Mail aufgenommen (siehe „Tests und Veröffentlichung“ später in diesem Kapitel), schreiben Sie sie also mit dem Publikum im Hinterkopf.

Der tatsächliche Aufbau der Quellcode-Dateien sollte der gleiche sein, oder zumindest so ähnlich wie möglich zu dem sein, den man aus der Versionsverwaltung herunterladen kann. Für gewöhnlich gibt es ein paar Unterschiede, zum Beispiel weil das Paket ein paar generierte Dateien enthält, die für die Konfiguration und Kompilierung benötigt werden (siehe „Kompilierung und Installation“ später in diesem Kapitel), oder weil es Software von dritten Parteien enthält, welches nicht von dem Projekt gepflegt wird, welches aber benötigt wird und die Benutzer wahrscheinlich nicht haben. Aber selbst wenn das Veröffentlichte Verzeichnis nicht genau dem Verzeichnis eines Entwicklungszweiges in der Versionsverwaltung entspricht, sollte die Distribution selbst, eine Arbeitskopie (siehe Arbeitkopie) sein. Die Veröffentlichung soll einen statischen Referenzpunkt repräsentieren – eine bestimmte, unveränderliche Konfiguration von Quellcode-Dateien. Wenn es eine Arbeitskopie wäre, gäbe es die Gefahr, dass der Nutzer es aktualisieren würde, und nachher denken, dass er die neue Version hat, während er tatsächlich etwas anderes hat.

Denken Sie daran, dass das Paket das gleiche ist, unabhängig von seiner Verpackung. Die Version – also genau die Entität, die gemeint ist, wenn jemand "Scanley 2.5.0" – sagt, ist das Verzeichnis, welches erstellt wird wenn die zip Datei oder der Tarball entpackt wird. Das Projekt könnte also all diese zum Herunterladen anbieten:

...aber der Quellcode-Baum, der beim entpacken entsteht, muss der gleiche sein. Dieser Quellcode-Baum ist die veröffentlichte Version; die Form in der es heruntergeladen wird, ist lediglich eine Sache der Bequemlichkeit. Bestimmte unwesentliche Unterschiede zwischen den Quellcode-Paketen sind zulässig: Zum Beispiel sollten in dem Windows Paket die Textdateien mit CRLF (Carriage Return und Line Feed) enden, während Unix-Pakete nur LF verwenden sollten. Die Verzeichnisse können auch leicht Unterschiedlich zwischen den verschiedenen Betriebssystemen angeordnet sein, wenn diese Betriebssysteme verschiedene Anordnungen für die Kompilierung erfordern. Das sind jedoch alles im wesentlichen triviale Transformationen. Die wesentlichen Quellcode-Dateien sollten über alle Pakete für eine Version die gleichen sein.

Bei Software, die eine Kompilierung oder Installation aus den Quellen erfordert, gibt es für gewöhnlich Standardverfahren, welche erfahrene Nutzer erwarten anwenden zu können. Bei Programmen die in C, C++, oder bestimmte anderen kompilierten Sprachen geschrieben sind, ist es in Unix-ähnlichen Systemen zum Beispiel für den Nutzer üblich, folgendes einzugeben:

   $ ./configure
   $ make
   # make install

Der erste Befehl erkennt automatisch, soviel von der Umgebung wie möglich, und bereitet den Build-Vorgang vor, der zweite Befehl kompiliert die Software im derzeitigen Pfad (installiert es jedoch nicht), und der letzte Befehl installiert es auf das System. Die ersten beiden Befehle werden als ganz normalen Nutzer ausgeführt, der dritte als root. Für weitere Details über die Einrichtung dieses Systems, siehe das ausgezeichnete GNU Autoconf, Automake, und Libtool Buch von Vaughan, Elliston, Tromey, und Taylor. Es ist als Treeware durch New Riders veröffentlicht worden, und sein Inhalt ist unter http://sources.redhat.com/autobook/. frei zugänglich.

Das ist nicht der einzige Standard, obwohl es einer der am weitesten verbreitetsten ist. Das Build-System Ant (http://ant.apache.org/) nimmt an Beliebtheit zu, insbesondere bei Projekten, die in Java geschrieben sind, und hat seine eigenen Abläufe für den Build und die Installation. Desweiteren, empfehlen bestimmte Programmiersprachen, wie Perl und Python, dass die gleiche Methode für die meisten Programme die in dieser Sprache geschrieben werden, benutzt werden (Perl-Module benutzten zum Beispiel den perl Makefile.PL Befehl). Wenn es für Sie nicht offensichtlich ist, welche Standards für Ihr Projekt gelten, fragen Sie einen erfahrenen Entwickler; Sie können mit Sicherheit davon ausgehen, dass irgend ein Standard gilt, selbst wenn Sie zuerst nicht wissen was es ist.

Was immer die entsprechenden Standards für Ihr Projekt auch sein mögen, weichen Sie nicht von Ihnen ab, es sei denn es ist zwingend notwendig. Standardabläufe bei der Installation sind mittlerweile praktisch Reflexe im Rückenmark vieler Systemadministratoren. Wenn sie bekannte Anweisungen in der INSTALL Datei von Ihrem Projekt erkennen, hebt es gleich ihr vertrauen darin, dass Ihr Projekt sich allgemein über Konventionen im klaren ist, und dass es wahrscheinlich ist, dass Sie auch andere Sachen richtig gemacht haben. Wie in „Downloads“ im Kapitel Kapitel 2, Der Einstieg beschrieben, erfreute es auch mögliche zukünftige Entwickler, wenn Sie standard Build-Verfahren benutzen.

Unter Windows, sind die Standards um einen Build zu machen und zu installieren weniger festgelegt. Bei Projekten die eine Kompilation erfordern, scheint die allgemeine Konvention zu sein, ein Verzeichnis zu Veröffentlichen, welches in dem Standardmodell für Arbeitsumgebungen/Projekte von den Entwicklungsumgebungen von Microsoft (Developer Studio, Visual Studio, VS.NET, MSVC++, usw.). Abhängig von der Natur Ihrer Software kann es möglich sein, eine Unix-ähnliche Build-Option mittels der Umgebung Cygwin (http://www.cygwin.com/) auf Windows anzubieten. Und wenn Sie natürlich eine Sprache oder einen Programmier-Framework verwenden, welches seine eigenen Konventionen für die Installation hat, – z.B, Perl oder Python – sollte Sie einfach die Standardmethode für dieses Framework benutzen, ob auf Windows, Unix, Mac OS X oder jedem anderen Betriebssystem.

Seien Sie bereit, zusätzliche Mühen auf sich zu nehmen, um Ihr Projekt konform zu den relevanten Build- und Installationsstandards zu machen. Build und Installation sind die Einstiegspunkte: Es ist in Ordnung, wenn Dinge nach diesem Einstieg schwieriger werden, falls denn überhaupt, es wäre aber schändlich, Benutzern oder Entwicklern gleich bei ihrer allererste Begegnung mit der Software unerwartete Schritte abzunötigen.

Auch wenn die formal veröffentlichte Version ein Quellcode-Paket ist, werden die meisten Nutzer von binären Paketen installieren, die entweder von dem Installationsprogramm ihres Betriebssystems angeboten wird, händisch von der Webseite Ihres Projekts besorgt wurden oder von irgend einer anderen dritten Partei. "Binär" bedeutet in diesem Zusammenhang nicht unbedingt "kompiliert"; es bedeutet lediglich irgend eine vorkonfigurierte Form des Pakets, welches es dem Nutzer erlaubt es auf seinen Computer zu installieren, ohne durch die üblichen Build und Installations-Abläufe der Quellcode basierenden Pakete. Auf RedHat GNU/Linux, ist es das RPM System; auf Debian GNU/Linux, ist es das APT (.deb) System; unter MS Windows, sind es üblicherweise .MSI Dateien oder selbst installierende .exe Dateien.

Ob diese binären Pakete von Personen die nahe an dem Projekt sind, zusammengestellt werden, oder entfernte dritte Parteien, die Nutzer werden sie als gleichwertig zu den offiziellen Veröffentlichungen des Projekts behandeln, und werden Meldungen auf den Bugtracker einreichen, auf der Grundlage des Verhaltens dieser binärpakete. Deshalb ist es im Interesse des Projekts denjenigen die Pakete schnüren, klare Richtlinien zu geben, und eng mit ihnen zusammen zu arbeiten, um dafür zu sorgen, dass was sie produzieren, die Software ordentlich und genau repräsentiert.

Die Hauptsache, die Ersteller von Paketen wissen müssen, ist, dass sie ihre binären Pakete immer aus offiziellen Quellcode-Pakete herleiten sollten. Manchmal sind sie versucht, eine spätere Version des Quellcodes aus dem Projektarchiv zu nehmen, oder ausgewählte Änderungen, die nach der Veröffentlichung committet wurden, zu integrieren, um den Nutzern bestimmte Bugfixes oder andere Verbesserungen anzubieten. Der Ersteller des Pakets denkt, dass er seinen Nutzern einen Gefallen tut, indem er ihnen neueren Code gibt, tatsächlich kann dieses Verfahren eine Menge Verwirrung verursachen. Projekte sind darauf vorbereitet, Bug-Meldungen zu bekommen, die in den neun Versionen gefunden werden, und Bugs die in dem derzeitigen Stamm und den Quellen des Hauptastes (das heißt, solche die von Personen gefunden werden, die den allerneusten Code verwenden). Wenn eine Bug-Meldung aus diesen Quellen kommt, wird der Antwortende oft in der Lage sein zu bestätigen, dass dieser Bug in der Momentaufnahme vorhanden ist, und vielleicht, dass es seitdem behoben wurde und dass der Nutzer eine Aktualisierung durchführen soll, oder auf die nächste Version warten soll. Wenn es ein vorher nicht bekannter Bug ist, machte es die Reproduktion und die Einordnung des Fehlers in dem Tracker einfacher, wenn man die genaue Version weiß.

Projekte sind jedoch nicht darauf vorbereitet, Meldungen von Bugs zu erhalten, die auf nicht spezifizierte oder hybrid Versionen basieren. Solche Bugs können schwer zu reproduzieren sein; sie können auch auf unerwartete Wechselwirkungen, zwischen einzelnen Änderungen zurück zu führen sein, die aus der späteren Entwicklung herausgezogen wurden, und deshalb Fehlverhalten verursachen, für die die Entwicklergemeinde die Schuld nicht tragen müssen sollte. Ich habe bestürzend viele Mengen an Zeit daran vergeudet gesehen, weil ein Bug gefehlt hat, wenn es hätte da sein sollen: jemand hatte eine leicht aktualisierte Version betrieben, die auf einer offiziellen (aber nicht identische) Version basierte, und als der vorhergesagte Bug nicht auftrat, mussten alle herumsuchen um herauszufinden, warum.

Trotzdem wird es manchmal Umstände geben, unter denen der Ersteller der Pakete darauf besteht, dass Änderungen an der Quellcode-Version nötig sind. Paket-Ersteller sollten dazu ermutigt werden, das bei den Entwicklern des Projekts zur Sprache zu bringen, und ihre Pläne zu beschreiben. Es mag sein, dass sie die Freigabe bekommen, wenn aber nicht, werden sie zumindest das Projekt über ihre Vorhaben informiert haben, damit das Projekt für die üblichen Bug-Meldungen Ausschau halten kann. Die Entwickler mögen reagieren, indem sie eine Ausschlussklausel auf ihre Webseite stellen, und den Paket-Ersteller darum bitten, das gleiche bei sich an angemessener Stelle zu machen, damit die Nutzer dieser binären Pakete wissen, dass was sie bekommen, nicht genau das gleiche ist, wie die offizielle Version. Es muss in einer solchen Situation keine Bitterkeit geben, obwohl es leider oft der Fall ist. Es ist nur, dass die Paket-Ersteller leicht unterschiedliche Ziele im Vergleich zu den Entwicklern verfolgen. Sie wollen hauptsächlich für ihre Nutzer die bestmögliche Erfahrung. Die Entwickler wollen das natürlich auch, sie müssen aber auch sicherstellen, dass sie wissen, welche Versionen der Software im Umlauf sind, damit sie verständliche Bug-Meldungen bekommen können und Garantien über die Kompatibilität machen können. Manchmal stehen diese Ziele im Konflikt zueinander. Wenn das der Fall ist, sollte man sich daran erinnern, dass das Projekt keine Kontrolle über die Paket-Ersteller hat, und dass das Schuldverhältnis in beiden Richtungen läuft. Es stimmt zwar, dass das Projekt den Paket-Erstellern einen Gefallen tut, alleine schon indem sie die Software erstellt. Die Paket-Ersteller tun dem Projekt aber auch einen Gefallen, indem sie die größtenteils unrühmliche Arbeit auf sich nehmen, die Software einer breiteren Masse zur Verfügung zu stellen, oftmals um mehrere Größenordnungen. Es ist in Ordnung, mit den Paket-Erstellern Meinungsverschiedenheiten zu haben, aber beleidigen Sie sie nicht; versuchen Sie einfach, sich mit ihnen so gut wie möglich zu verständigen.