In diesem Kapitel geht es darum, wie freie Software-Projekte ihre Software-Pakete erstellen und veröffentlichen, und wie sich allgemeine Entwicklungsmuster um diese Ziele herum organisieren. Ein großer Unterschied zwischen Open Source und proprietären Projekten ist der Mangel einer zentralen Kontrolle über das Entwicklerteam. Wenn eine neue Version vorbereitet wird, ist der Unterschied besonders gravierend: Ein Unternehmen kann das gesamte Entwicklerteam darum bitten, sich auf die bevorstehenden Version zu konzentrieren und die Entwicklung neuer Funktionen und die Behebung unkritischer Bugs ruhen zu lassen, bis die neue Version fertig ist. Gruppen von Freiwilligen sind nicht derart monolitisch. Sie arbeiten aus allen möglichen Gründen an dem Projekt, und diejenigen, die nicht daran interessiert sind, bei einer bestimmten Version zu helfen, wollen immer noch ihre normale Entwicklung weiterführen, während die neue Version vorbereitet wird. Da die Entwicklung niemals aufhört, neigen der Herausgabe-Prozesse in Open-Source-Projekten dazu, länger zu dauern, verursachen aber weniger Unruhe, als die kommerziellen Herausgabe-Prozesse. Es ist ein wenig wie die Reparatur einer Autobahn. Es gibt zwei Möglichkeiten, eine Straße zu reparieren: Sie können sie komplett absperren, damit die Reparaturmannschaft in voller Kapazität ausschwärmen kann, bis das Problem gelöst ist, oder Sie können jeweils nur ein paar Spuren gleichzeitig bearbeiten, während die anderen für den Verkehr offen bleiben. Die erste Methode ist sehr effizient für die Reparaturmannschaft, aber für niemanden sonst – die Straße ist komplett blockiert, bis die Arbeit erledigt ist. Die zweite Methode verursacht mehr Arbeitszeit und Kopfschmerzen für die Reparaturmannschaft (jetzt müssen sie mit weniger Leuten und Mitteln, unter eingeengten Bedingungen arbeiten, mit Schildern um den Verkehr zu verlangsamen und zu lenken, usw.), allerdings bleibt die Straße weiterhin benutzbar, wenn auch nicht mit der vollen Kapazität. Open-Source-Projekte tendieren dazu nach der zweiten Methode zu arbeiten. Bei einer ausgereiften Software ist es sogar so, dass mehrere verschiedene Versionslinien gleichzeitig gepflegt werden, das Projekt befindet sich in einer Art ständigen Straßenreparatur. Es sind immer ein paar Spuren geschlossen; beständige aber geringe Umstände im Hintergrund werden die ganze Zeit über von der Entwicklergemeinschaft toleriert, damit die neuen Version plangemäß fertig werden. Das Modell, das dies ermöglicht, lässt sich auf mehr als nur neue Versionen verallgemeinern. Es ist das Prinzip, Aufgaben zu parallelisieren, die nicht von einander abhängen – ein Prinzip das natürlich keinesfalls auf Open-Source-Entwicklung beschränkt ist, das jedoch von Open-Source-Projekten auf eine jeweils eigene bestimmte Art umgesetzt wird. Sie können es sich nicht leisten, ihre Straßenbau-Truppe oder den gewöhnlichen Verkehr zu sehr zu nerven, aber sie können es sich auch nicht leisten Leute dafür abzustellen, bei den orangen Kegeln zu stehen und den Verkehr zu dirigieren. Sie streben deshalb eher zu Abläufe die einen flachen, konstanten Grad an Mehraufwand haben, als Höhen und Tiefen. Freiwillige sind im Allgemeinen eher dazu bereit mit kleinen gleichbleibenden Mengen an Unbequemlichkeiten zu arbeiten; die Berechenbarkeit erlaubt es ihnen zu kommen und zu gehen, ohne sich darüber Sorgen zu machen, ob ihr Terminkalender mit dem was im Projekt passiert kollidiert. Wenn das Projekt aber eine einem Produktionsplan unterliegen würde, wäre das Ergebnis, eine Menge Entwickler die die meiste Zeit untätig herumsitzen – was nicht nur ineffizient wäre, sondern auch langweilig und dadurch gefährlich, insofern, dass ein gelangweilter Entwickler wahrscheinlich bald ein Ex-Entwickler sein wird. Arbeit an neuen Versionen ist für gewöhnlich die am ehesten bemerkbare Aufgabe die nicht zur Entwicklung gehört, welche neben der Entwicklung her läuft, also sind die Methoden die in den folgenden Abschnitten folgen meistens darauf ausgelegt neue Versionen zu ermöglichen. Beachten Sie jedoch, dass sie auch für andere Aufgaben gelten, die sich parallelisieren lassen, wie Übersetzungen und Lokalisierung, weitgreifende Änderungen an den Schnittstellen die nach und nach über den gesamten Quellcode gemacht werden, usw. Vor wir uns darüber unterhalten, wie man eine neue Version macht, lasst uns anschauen, wie man diese Versionen benennt, wozu wir wissen müssen was eine neue Version für die Benutzer tatsächlich bedeutet. Eine neue Version bedeutet, dass: Alte Bugs behoben wurden. Das ist wahrscheinlich eines der Sachen auf den sich die Benutzer für jede neue Version verlassen können. Neue Bugs wurden hinzugefügt. Darauf kann man sich für gewöhnlich auch verlassen, außer in manchen Fällen, bei der Behebung von Sicherheitslücken oder andere Einmalige Änderungen (siehe später in diesem Kapitel). Neue Funktionen können hinzugefügt worden sein. Neue Konfigurationseinstellung können hinzugefügt worden sein, oder die Bedeutung alter Einstellungen sich ein klein wenig geändert haben. Die Installationsabläufe können sich auch seit der letzten Version leicht geändert haben, auch wenn man immer hofft, dass das nicht der Fall ist. Nicht kompatible Änderungen können eingeführt worden sein, wie die Formatierung der Daten welche von älterer Software benutzt werden nicht weiter ohne irgend einer (möglicherweise händischen) Einweg-Konvertierung benutzt werden können. Wie sie sehen, ist nicht alles davon etwas gutes. Deshalb gehen erfahrene Benutzer immer mit ein wenig Angst an neue Versionen heran, ganz besonders, wenn die Software ausgereift ist und vorher schon zum größten Teil das gemacht hat, was sie wollten (oder dachten das sie wollten). Selbst der Einbau neuer Funktionen hat insofern nicht nur Vorteile, dass es bedeuten könnte, dass sich die Software jetzt unerwartet verhält. Der Sinn einer Versionsnummer ist deshalb zweifältig: Offensichtlich sollte die Nummer unzweideutig die Reihenfolge der Versionen mitteilen (d.h. wenn man sich zwei Versionsnummern anschaut, kann man unterscheiden, welches die später kam), sie sollten aber auch so kompakt wie möglich den Grad und Art der Änderungen in der Version andeuten. Das alles in einer Zahl? Nun, im Grunde genommen, ja. Die Strategien für Versionsnummern sind eine der ältesten Fahrradschuppen-Diskussionen, die es gibt (siehe im Kapitel ), und ist unwahrscheinlich, dass sich die Welt auf einen, vollständigen Standard in der irgendwann in der nächsten Zeit einigt. Ein paar gute Strategien sind aber entstanden, zusammen mit dem universell anerkannten Prinzip: konsistent zu sein. Wählen Sie ein Nummerierungsschema und bleiben Sie dabei. Ihre Nutzer werden es Ihnen danken. Dieser Abschnitt beschreibt im Detail die formalen Konventionen der Nummerierung von Versionen, und geht von sehr wenig Vorwissen aus. Es ist hauptsächlich als eine Referenz gedacht. Wenn Sie bereits mit diesen Konventionen vertraut sind, können Sie diesen Abschnitt überspringen. Eine Versionsnummer ist eine Gruppe von Zahlen die durch punkte getrennt sind: Scanley 2.3 Singer 5.11.4 ...und so weiter. Die Punkte sind keine Dezimalzeichen, sie sind lediglich Trennzeichen; nach "5.3.9" käme "5.3.10". Ein paar wenige Projekte haben ab und zu auf was anderes hingedeutet, am bekanntesten der Linux-Kernel mit seiner "0.95", "0.96"... "0.99" Reihe die zu Linux 1.0 hinführte, die Konvention, dass die Punkte keine Dezimalzeichen sind, ist jetzt aber fest etabliert und sollte als Standard betrachtet werden. Es gibt keine Grenze bei der Anzahl der Komponenten (Ziffernsequenzen, die keine Punkte enthalten), aber die meisten Projekte gehen nicht über drei oder vier hinaus. Die Gründe dafür werden später klar. Zusätzlich zu den numerischen Komponenten, hängen Projekte manchmal erläuternde Kennschrift wie "Alpha" oder "Beta" an (siehe ), als Beispiel: Scanley 2.3.0 (Alpha) Singer 5.11.4 (Beta) Ein Alpha- oder Beta-Vermerk bedeutet, dass diese Version einer zukünftigen vorausgeht welches die selbe Zahl haben wird, jedoch ohne den Vermerk. Deshalb führt "2.3.0 (Alpha)" letztendlich zu "2.3.0". Um mehrere solche Kandidaten in einer Folge zu ermöglichen, können die Vermerke selber Meta-Vermerke haben. Hier ist als Beispiel eine Serie von Versionen, in der Reihenfolge mit der sie veröffentlicht werden würden: Scanley 2.3.0 (Alpha 1) Scanley 2.3.0 (Alpha 2) Scanley 2.3.0 (Beta 1) Scanley 2.3.0 (Beta 2) Scanley 2.3.0 (Beta 3) Scanley 2.3.0 Beachten Sie, dass es mit dem "Alpha" Vermerk, Scanley "2.3" als "2.3.0" geschrieben wird. Die beiden Zahlen sind gleich – folgende Nullanteile können der Kürze halber immer weggelassen werden – wenn ein Vermerk aber vorhanden ist, ist die Kürze eh schon nicht gegeben, also kann man genau so gut vollständig ausschreiben. Andere Vermerke die mehr oder weniger oft benutzt werden sind "Stable" (de. stabil), "Unstable" (de. nicht stabil), "Development" (de. Entwicklerversion), und "RC" (für "Release Candidate") (de. Kandidat für eine finale Version). Die am weitesten verbreiteten sind immer noch "Alpha" und "Beta", mit "RC" nahe an dritter Stelle, beachten Sie aber, dass zu "RC" immer einen Meta-Vermerk gehört. Sie veröffentlichen als nicht "Scanley 2.3.0 (RC)", sondern "Scanley 2.3.0 (RC 1)", gefolgt von RC2, usw. Diese drei Vermerke, "Alpha", "Beta", und "RC", sind mittlerweile relativ gut bekannt, und ich empfehle nicht irgend welche andere zu benutzen, auch wenn andere auf dem ersten Blick passender erscheinen da sie normale Wörter sind, und kein Jargon. Diejenigen die neue Software-Versionen installieren, sind aber bereits mit den großen dreien vertraut, und es gibt keinen Grund die Sache grundlos anders von allen anderen zu machen. Obwohl die Punkte in Versionsnummer keine Dezimalzeichen sind, deuten sie doch einen Stellenwert an. Alle "0.X.Y" Versionen gehen "1.0" voraus (was natürlich gleichbedeutend ist mit "1.0.0"). "3.14.158" geht direkt "3.14.159" voraus, und indirekt "3.14.160", sowie "3.15.irgendwas" und ähnliches vorausgeht. Eine konsistente Richtlinie für die Numerierung der Versionen ermöglicht es den Benutzer zwei Versionsnummern der selben Software anzuschauen und alleine durch die Zahlen, die wichtigen Unterschiede zwischen ihnen zu unterscheiden. Bei einer typischen System aus drei Komponenten, ist die erste Komponente die major Nummer, die zweite ist die minor Nummer, und die dritte ist die micro Nummer. Version "2.10.17" ist zum Beispiel die siebzehnte Micro-Version in der zehnten Minor-Reihe innerhalb der zweiten Major-Versions-Serie. Die Worte "Reihe" (en. line) und "Serie" (en. series) werden hier informell verwendet, sie bedeuten aber was man erwarten würde. Eine Major-Serie ist lediglich alle Versionen die die gleich major Nummer teilen und eine minor Serie (oder Reihe) besteht aus allen Versionen welche die gleiche minor und major Nummer teilen. "2.4.0" und "3.4.1" sind also nicht in der selben minor Reihe, obwohl sie beide "4" als minor Nummer haben; andererseits sind, "2.4.0" und "2.4.2" in der selben Reihe, obwohl sie nicht auf einander folgen, wenn "2.4.1" zwischendurch veröffentlicht wurde. Die Bedeutung dieser Zahlen ist genau das, was man erwarten würde: Eine Erhöhung der major Nummer deutet auf große Änderungen hin; eine Erhöhung der minor Nummer deutet auf kleine Änderungen hin; und eine Erhöhung der micro Nummer deutet auf wirklich triviale Änderungen. Manche Projekte fügen eine vierte Komponente hinzu, gewöhnlich als patch Nummer bezeichnet, für besonders fein granulierte Kontrolle über die Unterschiede zwischen ihren Versionen (verwirrenderweise, benutzen andere Projekte "patch" als synonym für "micro" bei einem System mit drei Komponenten). Es gibt auch Projekte, welche die letzte Komponente als build Nummer verwenden, welches jedes mal hochgezählt wird, wenn ein neuer Build der Software gemacht wird und keine andere Änderung außer diesen Build repräsentiert. Das hilft dem Projekt jede Bug-Meldung mit einem bestimmten Build in Verbindung zu bringen, und ist wahrscheinlich am nützlichsten wenn binären Pakete die übliche Methode der Verteilung ist. Obwohl es viele verschiedene Konventionen gibt, wieviele Komponenten man verwenden soll, und was die Komponenten bedeutet, neigen die Unterschiede dazu unwesentlich zu sein – Sie haben ein wenig Spielraum aber nicht viel. Die nächsten beiden Abschnitte besprechen einige der am meisten benutzten Konventionen. Die meisten Projekte haben Regeln darüber, welche Arten von Änderungen bei einer neuen Version erlaubt sind wenn man nur eine micro Nummer erhöht, andere wenn man die minor Nummer erhöht und wieder andere bei der major Nummer. Es gibt noch keinen Satz von Normen für diese Regeln, ich werde hier aber eine Regelung beschreiben, die schon bei mehreren Projekten erfolgreich verwendet worden ist. Sie können diese Regelung für Ihr Projekt einfach übernehmen, aber selbst wenn Sie das nicht tun, ist es trotzdem ein gutes Beispiel für die Art von Informationen die Versionsnummern ausdrücken sollten. Diese Regelung basiert auf dem Nummernsystem, das vom APR-Projekt benutzt wird, siehe . Änderungen an der micro Nummer (d.h Änderungen innerhalb der selben minor Reihe) müssen sowohl aufwärts, als auch abwärtskompatibel sein. D.h. die Änderungen sollten nur Bugfixes sein, oder sehr kleine Verbesserungen an bestehenden Funktionen. Neue Funktionen sollten bei micro Versionen nicht eingeführt werden. Änderungen an der minor Nummer (d.h, innerhalb der selben major Reihe) müssen abwärtskompatibel sein, aber nicht unbedingt aufwärtskompatibel. Es ist normal neue Funktionen in einer minor Version einzuführen, für gewöhnlich aber nicht zu viele auf einmal. Änderungen an der major Nummer kennzeichnen Grenzen der Kompatibilität. Eine neue major Version kann zu vorhergehenden und folgenden Versionen inkompatibel sein. Von einer major Version werden neue Funktionen erwartet, und sogar ganze Sammlungen von Funktionen. Was abwärtskompatibel und aufwärtskompatibel genau bedeuten, hängt davon ab, was Ihre Software macht, im Kontext sind sie aber für gewöhnlich nicht sonderlich frei interpretierbar. Wenn Ihr Projekt zum Beispiel eine Client-Server-Anwendung ist, dann bedeutet "abwärtskompatibel", dass eine Aktualisierung auf 2.6.0 keine existierende 2.5.4 Clients Funktionen verlieren oder sich anders als vorher verhalten (natürlich abgesehen von den Bugs die behoben wurden). Eine Aktualisierung einer dieser Clients auf 2.6.0 zu aktualisieren könnte ihm andererseits neue Funktionen zur Verfügung stellen, bei dem die 2.5.4 Clients nicht wissen wie sie genutzt werden sollen. Wenn das passiert, dann ist die Aktualisierung nicht "aufwärtskompatibel": Sie können diesen Client nicht zurück auf 2.5.4 setzen und alle Funktionen aus 2.6.0 behalten, da manche dieser Funktionen bei 2.6.0 neu waren. Deshalb sind micro Versionen im wesentlichen ausschließlich zur Behebung von Fehler. Sie müssen in beiden Richtungen kompatibel bleiben: Wenn Sie von 2.5.3 auf 2.5.4 aktualisieren, Ihre Meinung dann ändern und wieder zurück auf 2.5.3 wechseln, sollten keine Funktionen verloren gehen. Die Fehler, die durch 2.5.4 behoben wurden, würden natürlich wieder auftauchen, aber Sie würden keine Funktionen verlieren, außer insofern, dass die wiederhergestellten Fehler die Nutzung existierender Funktionen verhindert. Client-Server-Protokolle sind nur eines vieler möglicher Kompatibilitätsbereiche. Ein weiteres sind Datenformate: Schreibt die Software auf ein permanentes Speichermedium? Wenn ja, müssen die Formate die es liest und schreibt die Kompatibilitätsrichtlinien die von den durch die Versionsnumeriertung versprochenen Richtlinien befolgen. Version 2.6.0 muss in der Lage sein die Dateien die von 2.5.4 geschrieben wurden zu lesen, kann aber im Stillen das Format auf etwas erweitern, welches 2.5.4 nicht lesen kann, da die Fähigkeit auf eine vorherige Version zu wechseln, nicht über die Grenze einer major Nummer erforderlich ist. Wenn Ihr Projekt Code-Bibliotheken, für die Nutzung durch andere Anwendungen, vertreibt, dann sind die Schnittstellen auch Bereich indem die Kompatibilität gewahrt werden muss: Sie müssen dafür sorgen, dass die Regeln für die Kompatibilität von Quellcode und Binärdateien, derart formuliert sind, dass ein informierter Nutzer sich niemals fragen muss, ob es sicher ist zu aktualisieren. Er wird in der Lage sein die Zahlen anzusehen, und es sofort zu wissen. Bei diesem System, bekommen Sie keine Gelegenheit für einen sauberen Neuanfang, bis sie die major Nummer hochzählen. Das kann oft lästig sein: Es mag Funktionen geben, die Sie hinzufügen wollen, oder Protokolle, die Sie neu entwerfen wollen, was einfach nicht gemacht werden können, während Sie die Kompatibilität wahren. Es gibt hierfür keine magische Lösung, außer zu versuchen alles von vorn herein so zu entwerfen, dass es sich leicht erweitern lässt (ein Thema welches man leicht ein ganzes Buch widmen könnte, und sicherlich außerhalb des Rahmens von diesem). Die Kompatibilitätsrichtlinien zu veröffentlichen und sich an ihnen zu halten, ist ein unausweichlicher Teil beim Vertrieb von Software. Eine böse Überraschung kann viele Nutzer abschrecken. Die eben beschriebene Richtlinie ist zum Teil deshalb gut, da sie bereits ziemlich weit verbreitet ist, aber auch weil sie leicht zu erklären und zu behalten ist, selbst solche, die noch nicht damit vertraut sind. Ist ist allgemein anerkannt, das diese Regeln nicht für Versionen vor 1.0 gelten (obwohl Ihre Versionsrichtlinien, um Missverständnisse zu vermeiden, das trotzdem explizit sagen sollte). Ein Projekt, welches sich noch in der frühen Entwicklung befindet, kann 0.1, 0.2, 0.3, usw. in einer Reihe veröffentlichen, bis es für 1.0 bereit ist, und die Unterschiede zwischen den Versionen können beliebig groß sein. Micro-Nummern in einer pre-1.0 Version sind optional. Abhängig von der Natur Ihres Projekts, und die Unterschiede zwischen den Versionen, werden Sie es nützlich finden, 0.1.0, 0.1.1, usw. zu haben oder nicht. Konventionen für pre-1.0 Versionsnummern sind relativ locker, hauptsächlich deshalb, weil Leute verstehen, dass strenge Einschränkungen für Kompatibilität die frühe Entwicklung zu sehr behindern würde, und weil Personen die ein Produkte in ihren frühen Phasen benutzen, sowieso etwas nachsichtig sind. Denken Sie daran, dass all diese Vorschriften nur für dieses bestimmte Drei-Komponenten-System gelten. Ihr Projekt kann sich ganz leicht ein anderes Drei-Komponenten-System ausdenken, oder sich gar entscheiden, dass es keine derart feine Granularität benötigt und statt dessen ein Zwei-Komponenten-System verwenden. Das wichtige ist, sich frühzeitig zu entscheiden, genau zu veröffentlichen, was die Komponenten bedeuten, und dabei zu bleiben. Manche Projekte benutzen die Parität der Minor-Nummer, um auf die Stabilität der Software zu deuten: gerade bedeutet stabil, ungerade bedeutet instabil. Das gilt nur für die Minor-Nummer, nicht für die Major- oder Micro-Nummern. Eine Erhöhung in der Micro-Nummer deutet immer noch auf Fehlerbehebungen hin (keine neuen Funktionen), und eine Erhöhung der Major-Nummer deutet auf große Änderungen, neue Funktionen, usw. hin. Der Vorteil des Gerade/Ungerade-Systems, welches unter anderem vom Linux-Kernel-Projekt verwendet wurde ist, dass es eine Möglichkeit bietet, neue Funktionen zum Test anzubieten, ohne die Nutzer in Produktivsystemen möglicherweise instabilen Code auszusetzen. Die Leute können durch die Zahlen erkennen, dass es sicher ist, "2.4.21" auf ihren im Einsatz befindliche Webserver zu installieren, aber dass "2.5.1" besser für Experimente auf dem heimischen Rechner beschränkt bleiben sollten. Das Entwicklerteam befasst sich mit den Bug-Meldungen die aus der instabilen (ungerade numerierten) Reihe kommen, und wenn sich die Sache nach ein paar Micro-Versionen langsam legt, erhöhen sie die Minor-Nummer (wodurch sie gerade gemacht wird), setzen die Micro-Nummer wieder auf "0", und veröffentlichen ein vermutlich stabiles Paket. Dieses System bewahrt die vorhin erwähnten Kompatibilitsrichtlinien, oder tritt zumindest nicht im Konflikt ihnen. Es fügt der Minor-Nummer lediglich ein paar Informationen hinzu. Das zwingt die Minor-Nummer dazu ungefähr doppelt so oft erhöht zu werden, als das sonst der Fall wäre, was aber kein großer schaden ist. Das Gerade/Ungerade-System ist wahrscheinlich am besten für Projekte geeignet, die sehr lange Entwicklungszyklen haben, und von Natur aus einen großen Anteil konservativer Nutzer haben, die mehr Wert auf Stabilität als auf neue Funktionen setzen. Es ist jedoch nicht die einzige Möglichkeit, neue Funktionen im Feld getestet zu bekommen. später in diesem Kapitel beschreibt eine weitere, vielleicht gebräuchlichere Art, potentiell instabilen Code zu veröffentlichen, der in einer Weise gekennzeichnet ist, die den Leuten bereits aus dem Namen der Version eine Vorstellung von dem mit ihr verbundenen Risiko/Nutzen-Kompromiss vermittelt. Aus der Sicht eines Entwicklers, ist ein freies Software-Projekt, in einem ständigen Zustand der Veröffentlichung. Entwickler betreiben für gewöhnlich zu jeder Zeit die aktuellste Version, da sie Fehler entdecken wollen, und da sie das Projekt dicht genug verfolgen, um von derzeit instabilen Bereichen des Funktionsumfangs fern zu bleiben. Sie aktualisieren ihre Kopie der Software für gewöhnlich jeden tag, manchmal öfter, und wenn Sie eine Änderung abschicken, können sie halbwegs erwarten, dass jeder andere Entwickler es innerhalb von 24 Stunden haben wird. Wie sollte das Projekt dann eine formale Veröffentlichung machen? Sollte es einfach eine Momentaufnahme vom derzeitigen Zustand des Quellcode-Baums machen, und es der Welt als, sagen wir, "3.5.0" überreichen? Die Vernunft sagt nein. Erstens gäbe es möglicherweise keinen einzelnen Zeitpunkt, bei dem der ganze Quellcode-Baum bereit für eine neue Version ist. Neu angefangene Funktionen könnten an verschiedenen Stellen, in verschiedenen Zuständen der Fertigstellung herumliegen. Jemand könnte eine riesige Änderung committed haben, um einen Fehler zu beheben, die Änderung könnte aber kontrovers sein und zu der Zeit debattiert werden indem die Momentaufnahme gemacht wird. Wenn das der Fall ist, würde es nicht so einfach funktionieren, die Momentaufnahme zu verzögern, bis die Debatte beendet ist, da eine andere, nicht im Zusammenhang stehende Debatte in der Zwischenzeit anfangen könnte, und dann müssten Sie wieder darauf warten. Man kann nicht garantieren, dass dieser Ablauf aufhören wird. In jedem Fall, würde die Nutzung von Momentaufnahmen des kompletten Quellcode-Baums als eine neue Version, die fortlaufenden Entwicklung behindern, selbst wenn der Quellcode in einem für die Veröffentlichung geeigneten Zustand gebracht werden könnte. Sagen wir, dass diese Momentaufnahme "3.5.0" sein wird; wäre die nächste Version vermutlich Bugfixes beinhalten, die in 3.5.0 gefunden wurden. Wenn beide Momentaufnahmen aber vom gleichen Baum sein sollen, was sollen die Entwickler in der Zeit zwischen den beiden Versionen machen? Sie können keine neuen Funktionen hinzufügen; dass verbieten die Kompatibilitätsrichtlinien. Aber nicht alle werden enthusiastisch darüber sein Fehler in dem Code von 3.5.0 zu beheben. Manche werden neue Funktionen haben, die sie versuchen fertigzustellen, und würden wütend werden, wenn sie dazu gezwungen wären zu wählen zwischen, untätig herum zu sitzen oder an Sachen zu arbeiten, die sie nicht interessieren, nur weil der Ablauf des Projekts beim Erstellen einer neuen Version erfordert, dass die Entwicklung an dem Codebaum unnatürlich ruhig bleibt. Die Lösung für diese Probleme ist, immer einen Versionszweig (en. release branch) zu benutzen. Ein Versionszweig ist lediglich ein Zweig in dem Versionsverwaltungssystem, (siehe ), bei dem der Code, welcher für diese Release bestimmt ist, von der Hauptentwicklung getrennt werden kann. Diese Zweige sind sicherlich kein originäres Konzept freier Software; viele kommerzielle Unternehmen, die Software entwickeln, benutzen sie auch. In kommerziellen Umgebungen werden Versionszweige jedoch manchmal als ein Luxus betrachtet – eine Art formales "optimales Verfahren" (en. "best practice") welches unter dem Druck eines wichtigen Termins entfallen kann, während alle Entwickler sich dabei beeilen, den Hauptast stabil zu bekommen. Versionszweige sind jedoch bei Open-Source-Projekten so ziemlich eine Notwendigkeit. Ich habe Projekte gesehen, die neue Versionen ohne sie machen, das Ergebnis war jedoch immer, dass einige Entwickler untätig herumsaßen, während einige andere – für gewöhnlich eine Minderheit – daran arbeiten die Version fertigzustellen. Dieses Ergebnis ist gewöhnlicherweise auf verschieden Arten schlecht. Erstens, verlangsamt sich die Geschwindigkeit der Entwicklung insgesamt. Zweitens, ist die neue Version von einer schlechteren Qualität als es hätte sein müssen, da nur wenige daran gearbeitet haben, und die hatten es eilig, damit alle anderen wieder an die Arbeit gehen konnten. Drittens, spaltet es psychologisch die Entwicklermannschaft, indem es eine Situation aufbaut, bei dem verschiedene Arten der Arbeit sich gegenseitig unnötig stören. Die Entwickler die untätig herumsitzen, wären wahrscheinlich froh etwas von ihrer Aufmerksamkeit zu dem Versionszweig beizutragen, solange es eine Wahl bleibt, die sie abhängig von ihren Interessen und Zeitplänen treffen könnten. Ohne den Zweig, beschränkt sich ihre Auswahl jedoch auf "Nehme ich heute an dem Projekt teil oder nicht?" anstatt "Arbeite ich heute an der neuen Version, oder an der neuen Funktion in dem Hauptzweig, dass ich Entwickele?". Die genaue Mechanik der Erstellung eines Versionszweiges hängt natürlich von Ihrem Versionsverwaltungssystem ab, die allgemeinen Konzepte sind aber für die meisten Systemen gleich. Ein Zweig sprießt für gewöhnlich aus einem anderen Zweig under dem Stamm. Traditionell, wird die Entwicklung in dem Stamm betrieben, ungestört von den Einschränkungen einer neuen Version. Der erste Zweig, welcher zu der Version "1.0" führt, sprießt vom Stamm ab. Bei CVS sähe der Befehl für einen Zweig ungefähr wie folgt aus: $ cd trunk-working-copy $ cvs tag -b VERSION_1_0_X Oder in Subversion, wie folgt: $ svn copy http://.../repos/trunk http://.../repos/branches/1.0.x (All diese Beispiele gehen von dem Drei-Komponenten-System für die Nummerierung der Version aus. Obwohl ich nicht die genauen Befehle für jedes Versionsverwaltungssystem geben kann, sind hier Beispiel für CVS und Subversion und ich hoffe, dass die entsprechenden Befehle von den beiden abgeleitet werden können.) Beachten Sie, dass wir den Zweig "1.0.x" (mit dem Buchstaben "x") anstatt "1.0.0" erzeugt haben. Das liegt daran, dass die selbe Minor-Reihe – d.h. der selbe Ast – für alle Micro-Versionen in der Reihe benutzt werden wird. Der eigentliche Vorgang, den Zweig für die Veröffentlichung stabil zu machen, wird in später in diesem Kapitel behandelt. Hier geht es nur um die Wechselwirkung zwischen dem Versionsverwaltungssystem und dem Ablauf beim Erstellen der neuen Version. Sobald der Versionszweig in einen stabilen Zustand gebracht wurde und bereit ist, wird es Zeit, eine Momentaufnahme von dem Zweig zu machen: $ cd VERSION_1_0_X-working-copy $ cvs tag VERSION_1_0_0 or $ svn copy http://.../repos/branches/1.0.x http://.../repos/tags/1.0.0 Dieses Tag repräsentiert jetzt genau den Zustand, in dem der Quellcode des Projekts war bei der Version 1.0.0 (das ist nützlich, falls Sie je eine ältere Version brauchen, nachdem die veröffentlichten Pakete nicht mehr zur Verfügung stehen). Die nächste Micro-Version in der selben Reihe, wird gleichermaßen in dem 1.0.x Zweig vorbereitet, und wenn es bereit ist, wird ein Tag für 1.0.1. gemacht. Gleiches gilt für 1.0.2, usw. Wenn es Zeit wird, über eine neue 1.1.x-Version nachzudenken, erzeugen Sie einen neuen Zweig vom Stamm: $ cd trunk-working-copy $ cvs tag -b VERSION_1_1_X oder $ svn copy http://.../repos/trunk http://.../repos/branches/1.1.x Die Wartung kann parallel dazu in den Versionen 1.0.x und 1.1.x, weitergehen, und neue Versionen können in beiden Reihen unabhängig von einander veröffentlicht werden. Es ist sogar nicht einmal ungewöhnlich zwei Versionen aus verschiedenen Reihen zur gleichen Zeit zu veröffentlichen. Die ältere Reihe wird für die konservativeren Server Administratoren empfohlen, die vielleicht nicht den großen Sprung nach (sagen wir) 1.1 machen wollen, ohne sorgfältige Vorbereitung. In der Zwischenzeit, nehmen die eher abenteuerlustigen Personen die neuste Version der höchsten Reihe, um sicher zu sein, dass sie all die neusten Funktionen bekommen, selbst mit dem Risiko einer höheren Instabilität. Das ist natürlich nicht die einzige Strategie für neue Versionszweige. Unter manchen Umständen mag es nicht einmal die beste sein, obwohl es für die Projekte mit denen ich zu tun hatte ziemlich gut funktioniert hat. Benutzen Sie irgend eine Strategie die zu funktionieren scheint, bedenken Sie aber die wichtigsten Punkte: Der Sinn eines Versionszweiges ist, die Arbeit an der neuen Version von den Schwankungen der täglichen Entwicklung zu trennen, und dem Projekt eine Physikalische Entität zu geben, um den es die Abläufe bei der Veröffentlichung organisieren kann. Diese Abläufe werden im nächsten Abschnitt detailliert beschrieben. Stabilisierung ist der Vorgang, den Zweig einer neue Version in einem Zustand zu bringen, der für die Veröffentlichung geeignet ist; mit anderen Worten, zu entscheiden, welche Änderungen in der Version sein werden, welche nicht, und den Inhalt vom Zweig entsprechend zu gestalten. Es gibt eine menge möglichen Kummer in diesem Wort "entscheiden". Der Ansturm neuer Funktionen in der letzten Minute ist ein bekanntes Phänomen bei gemeinschaftlichen Software-Projekten: Sobald Entwickler sehen, dass eine neue Version gleich gemacht wird, beeilen sie sich ihre derzeitigen Änderungen fertig zu bekommen, um den Zug nicht zu verpassen. Das ist natürlich genau das Gegenteil, von dem was Sie zum Zeitpunkt einer neuen Version haben wollen. Es wäre viel besser, wenn Leute in einem gemütlichen Tempo an neue Funktionen arbeiten, und sich nicht all zu viele sorgen darüber machen ob Ihre Änderungen es in diese Version oder die nächste schaffen. Je mehr Änderungen man versucht in eine neue Version in der letzten Minute zu quetschen, desto mehr Code wird instabil gemacht, und (für gewöhnlich) desto mehr neue Bugs werden erzeugt. Die meisten Programmierer sind sich theoretisch über grobe Kriterien einig, welche Änderungen in eine Versionsreihe hereingelassen werden sollten, währen der Stabilisierungsphase. Offensichtlich, können Fixes für schwerwiegende Bugs reingehen, insbesondere wenn es keine Möglichkeit gibt sie zu umgehen. Aktualisierungen der Dokumentation sind in Ordnung, genau so wie der Text von Fehlermeldungen (außer wenn man sie als einen Teil der Schnittstelle betrachtet und stabil bleiben müssen). Viele Projekte erlauben also bestimmte Arten risikoarmer nicht grundsätzlicher Änderungen während der Stabilisierungsphase einzubinden, und können formale Richtlinien darüber haben, um das Risiko einzustufen. Keine Maß der Formalisierung kann jedoch die Notwendigkeit menschlichen Urteils obsolet machen. Es wird immer Fälle geben, bei dem das Projekt eine Entscheidung treffen muss, ob eine bestimmte Änderung in eine neue Version gehen kann. Die Gefahr ist, dass da jede Person ihre eigen Lieblingsängerungen aufgenommen haben will, wird es eine Menge Leute geben, die motiviert sind Änderungen zu erlauben, und nicht genügend die motiviert sind, sie zu verhindern. Der Ablauf, eine neue Version zu stabilisieren dreht sich deshalb größtenteils darum, "nein" zu sagen. Der Trick insbesondere für Open-Source-Projekte ist, sich Wege auszudenken "nein" zu sagen, die nicht mit allzu vielen verletzten Gefühlen oder enttäuschten Entwicklern enden und die es dennoch ermöglichen, dass Änderungen in neue Versionen aufgenommen werden, die es verdienen. Es gibt viele verschiedene Wege das zu erreichen. Es ist ziemlich leicht Systeme zu entwerfen, welche diesen Kriterien gerecht werden, nachdem sich das Team auf sie als die wichtigsten Kriterien konzentriert hat. Ich werde hier knapp zwei der verbreitetsten Systeme beschreiben, die an den extremen Enden des Spektrums liegen, lassen Sie Ihr Projekt hiervon aber nicht abhalten, kreativ zu sein. Eine Menge anderer Reglungen sind möglich; diese sind lediglich zwei von denen ich gesehen habe, dass sie in der Praxis funktionieren. Die Gruppe einigt sich darauf, dass eine Person der Versionsherr (en. release owner) sein wird. Diese Person hat das letzte Wort darüber, welche Änderungen es in die neue Version schaffen. Es ist natürlich normal und wird erwartet, dass es Diskussionen und Auseinandersetzungen gibt, letztendlich muss die Gruppe der Person die nötige Autorität geben um endgültige Entscheidungen zu treffen. Damit dieses System funktioniert, ist es nötig, jemand zu wählen, der die nötige technische Kompetenz hat um alle Änderungen zu verstehen, und den sozialen Stand und Fähigkeiten im Umgang mit Menschen um die Diskussionen zu führen, die einer neuen Version vorausgehen, ohne zu viele verletzte Gefühle zu verursachen. Ein häufiges Muster ist, dass der Versionsherr sagt "Ich denke nicht, dass es irgend etwas an dieser Änderung auszusetzen gibt, aber wir haben noch nicht genug Zeit gehabt, um es zu testen, also sollte es nicht in diese Version gehen". Es hilft eine Menge wenn der Versionsherr ein breites technisches Wissen über das Projekt hat, und Gründe angeben kann, warum eine Änderung möglicherweise destabilisierend sein könnte (zum Beispiel seine Wechselwirkung mit andern Teilen der Software oder Bedenken im Bezug auf die Kompatibilität). Manche werden nach einer Rechtfertigung für solche Entscheidungen fragen, oder argumentieren, dass eine Änderung nicht so gefährlich ist wie sie aussieht. Diese Unterhaltungen müssen nicht konfrontierend sein, so lange der Versionsherr alle Argumente objektiv in Erwägung ziehen kann, und nicht aus reflex auf seinen Standpunkt beharrt. Beachten Sie, dass der Versionsherr nicht die gleiche Person sein muss, wie der Projektleiter (bei solchen Fällen wo es überhaupt einen Projektleiter gibt; siehe im Kapitel ). Manchmal ist es sogar gut, wenn sie nicht ein und die selbe Person sind. Die Fähigkeiten die einen gute Projektleiter ausmachen, sind nicht unbedingt die gleichen, die einen guten Versionsherr ausmachen. Bei etwas derart wichtigem wie die Veröffentlichung neuer Versionen, kann es klug sein, jemanden zu haben, der ein Gegengewicht zu dem Urteil vom Projektleiter bildet. Vergleichen Sie die Rolle des Versionsverwalters mit der weniger diktatorischen Rolle beschrieben in später in diesem Kapitel. Bei dem anderen extrem, von der Diktatur durch den Versionsherr, können Entwickler einfach darüber abstimmen, welche Änderungen in einer neun Version aufgenommen werden. Da die wichtigste Aufgabe bei der stabilisierung einer neun Version der Ausschluss von Änderungen ist, ist es wichtig, das Wahlsystem so zu gestalten, dass eine Änderung in eine Version zu bekommen die Zustimmung mehrerer Entwickler bedarf. Eine Änderung aufzunehmen, sollte mehr als eine einfache Mehrheit erfordern (siehe im Kapitel ). Andererseits würde eine Stimme für eine Änderung und keine dagegen ausreichen, es in die Version zu bekommen und eine unglückliche Dynamik würde einsetzen, bei dem jeder Entwickler für seine eigenen Änderungen stimmen würde, jedoch widerwillig gegen die Änderungen anderer stimmen würde, aus Angst vor einer möglichen Vergeltung. Um das zu vermeiden, sollte das System derart ausgelegt sein das Untergruppen von Entwickler zusammen agieren müssen um irgend eine Änderung in eine Version zu bekommen. Das bedeutet nicht nur, dass mehr Personen jede Änderung überprüfen, es macht auch jeden Entwickler weniger zögerlich gegen eine Änderung zu stimmen, da kein bestimmter Entwicklern der dafür gestimmt hat, seine Gegenstimme es als einen persönlichen Angriff betrachten würde. Je mehr Leute beteiligt sind, desto mehr dreht sich die Entscheidung um die Änderung und weniger um die Individuen. Das System welches wir beim Subversion-Projekt benutzen, scheint ein gutes Gleichgewicht getroffen zu haben, also werde ich es hier empfehlen. Damit eine Änderung auf einen Versionszweig angewandt werden kann, müssen mindestens drei Entwickler dafür stimmen, und keiner dagegen. Eine einzige Gegenstimme reicht aus, um zu verhindern, dass eine Änderung angewandt wird; in dem Kontext einer neuen Version heißt das also, dass eine Gegenstimme gleichbedeutend mit einem Veto ist (siehe ). Jede solche Gegenstimme muss natürlich von einer Rechtfertigung begleitet werden, und theoretisch kann das Veto aufgehoben werden, wenn genügend der Meinung sind, dass unvernünftig ist und eine besondere Abstimmung darüber erzwingen. In der Praxis, ist das nie vorgekommen und ich erwarte nicht, dass es das jemals wird. Bei einer neuen Version sind sowieso alle schon konservativ eingestellt, und wenn jemand es als dringend genug erachtet, ein Veto einzulegen, dann gibt es für gewöhnlich einen guten Grund dafür. Da da der Ablauf eine neue Version zu erstellen, absichtlich eine konservative Voreingenommenheit hat, sind die Rechtfertigungen die bei Vetos angeboten werden manchmal eher formal als technisch orientiert. Eine Person kann zum Beispiel das Gefühl haben, dass eine Änderung gut geschrieben ist und wahrscheinlich keine neuen Fehler verursachen wird, aber gegen die Aufnahme der Änderung in einer micro Version stimmt, einfach weil es zu groß ist – vielleicht fügt es eine neue Funktion hinzu, oder auf irgend eine subtile Art, die Kompatibilitätsrichtlinien nicht befolgt. Ich habe gelegentlich sogar Entwickler gesehen, die ein Veto eingelegt haben, einfach nur aus einem Bauchgefühl heraus, dass die Änderung mehr getestet werden musste, auch wenn sie bei der Überprüfung keine Fehler entdecken konnten. Leute murrten ein wenig, aber die Vetos blieben in Kraft, und die Änderung wurde bei der Version nicht aufgenommen (ich kann mich allerdings nicht daran erinnern ob bei den weiteren Tests irgend welche Fehler gefunden wurden oder nicht). Wenn Ihr Projekt sich für ein System entscheidet bei dem über Änderungen abgestimmt wird, ist es unabdingbar, dass die physikalischen Mechanismen, die Wahl zusammen zu stellen und Stimmen, so bequem wie möglich ist. Obwohl es eine menge Open-Source-Software für elektronische Wahlen zur Verfügung steht, ist in der Praxis, am einfachsten, eine Textdatei im Versionszweig zu erstellen, mit dem Namen STATUS oder VOTES oder etwas ähnliches. Diese Datei listet jede vorgeschlagene Änderung auf – alle Entwickler können eine neue Änderung für die Aufnahme vorschlagen – zusammen mit allen Stimmen dafür oder dagegen, mit zusätzlichen Anmerkungen oder Kommentare. (Eine Änderung vorzuschlagen bedeutet im übrigen nicht unbedingt dafür zu stimmen, auch wenn die beiden oftmals hand in hand gehen.) Ein Eintrag in einer solchen Datei, könnte wie folgt aussehen: * r2401 (Meldung #49) Verhindern, dass der client/server handshake zwei mal durchgeführt wird. Rechtfertigung: Vermeidet überflüssigen Netzwerkverkehr; kleine Änderung und leicht zu überprüfen. Anmerkungen: Wurde in http://.../mailing-lists/message-7777.html und anderen Nachrichten in dem Thread besprochen. Stimmen: +1: jsmith, kimf -1: tmartin (Bricht die Kompatibilität mit manchen pre-1.0 Server; zugegeben, diese Server sind Buggy, aber warum sollen wird inkompatibel sein, wenn es nicht sein muss?) In diesem Fall, erhielt die Änderung zwei positive Stimmen, wurde aber durch den Veto von tmartin aufgehalten, der den Grund für seinen Einspruch in Klammern angegeben hat. Das genau Format von diesem Eintrag macht keinen Unterschied; egal worauf sich Ihr Projekt einigt, es ist in Ordnung – vielleicht sollte die Erklärung von tmartin für seinen Einspruch in den "Anmerkungen:" Bereich gehen, oder vielleicht sollte die Beschreibung der Änderung eine "Beschreibung:" Überschrift bekommen um den anderen Abschnitten zu entsprechen. Dass wichtige ist, dass alle Information, die nötig ist, um die Änderung zu evaluieren zur Verfügung stehen und dass die Mechanismen um Stimmen abzugeben, so einfach wie möglich sind. Die vorgeschlagene Änderung wird anhand seiner Revisionsnummer im Projektarchiv gekennzeichnet (in diesem Fall eine einzige Revision, r2401, obwohl eine vorgeschlagene Änderung genau so gut aus mehreren Änderungen bestehen könnte). Von der Revision wird angenommen, dass sie sich auf den Stamm bezieht; wenn die Änderung bereits im Versionszweig wäre, gäbe es keinen Grund darüber abzustimmen. Wenn Ihr Versionsverwaltungssystem keine offensichtliche Syntax hat, um auf einzelne Revisionen zu verweisen, sollte das Projekt eins erfinden. Damit Abstimmungen durchgeführt werden können, müssen Änderungen die in Frage stehen, eindeutig zu identifizieren sein. Diejenigen die einen Vorschlag einreichen, oder dafür abstimmen, sind dafür verantwortlich, dass es sauber auf den Versionszweig angewandt werden kann, d.h. ohne Konflikte (siehe ) angewandt werden kann. Wenn es Konflikte gibt, sollte der Eintrag entweder auf einen angepassten Zweig verweisen, auf dem sich der Patch sauber anwenden lässt, oder auf einen temporären Zweig welcher eine angepasste Version der Änderung beinhaltet, zum Beispiel: * r13222, r13223, r13232 Überarbeitung vom auto-merge Algorithmus in libsvn_fs_fs Rechtfertigung: Nicht akzeptable Performance (>50 Minuter für einen kleinen commit) bei einem Projektarchiv mit 300,000 Revisionen Zweig: 1.1.x-r13222@13517 Stimmen: +1: epg, ghudson Dieses Beispiel stammt aus dem echten Leben; es stammt aus der STATUS Datei für Version 1.1.4 von Subversion. Beachten Sie, wie es die ursprünglichen Revisionen als kanonische Verweise auf die Änderung benutzt obwohl es auch einen Zweig gibt, indem die aufgrund von Konflikten angepasste Version der Änderung enthalten ist (der Zweig kombiniert auch die drei Revisionen im Stamm zu einer, r13517, um dem Merge zum Zweig der neuen Version zu erleichtern, sollte ihm zugestimmt werden). Die ursprünglichen Revisionen werden angegeben, da sie trotzdem noch am einfachsten zu überprüfen sind, da sie die ursprünglichen commit Kommentare enthalten. Der vorübergehende Zweig hätte diese Kommentar nicht; um eine Verdopplung der Informationen zu vermeiden (siehe im Kapitel ), der Commit Kommentar für r13517 einfach sagen "Anpassung von r13222, r13223, und r13232 für die Portierung auf den 1.1.x Zweig." Alle anderen Information über die Änderung kann bei ihren ursprünglichen Revisionen gefunden werden. Der eigentliche Merge-Vorgang (siehe ) angenommener Änderungen in den Versionszweig kann von jedem Entwickler durchgeführt werden. Es muss keine bestimmte Person geben, deren Aufgabe es ist, die Änderungen zu mergen; wenn es eine große Menge von Änderungen gibt, kann es besser sein, die Bürde zu verteilen. Obwohl sowohl Wahlen als auch die Merges auf eine dezentralisierte Art passieren, gibt es in der Praxis ein oder zwei Personen welche die Veröffentlichung vorantreiben. Diese Rolle wird manchmal als Releaseverwalter (en. release manager) bezeichnet, sie ist aber sehr verschieden von einem Versionsherr (siehe früher in diesem Kapitel) der das letzte Wort über die Änderungen hat. Versionsverwalter halten einen Überblick darüber, wie viele Änderungen derzeit in Betracht gezogen werden, wie vielen zugestimmt wurde, und wie vielen wahrscheinlich zugestimmt wird, usw. Wenn sie das Gefühl bekommen, dass wichtige Änderungen nicht die nötige Aufmerksamkeit bekommen, und aus einer Version gelassen werden könnten, aufgrund von Stimmenmangel, werden sie sanft andere Entwickler nerven, damit sie die Änderungen überprüfen und darüber abzustimmen. Wenn ein Satz von Änderungen Zustimmung erhalten haben, werden diese Personen es oft auf sich nehmen, sie in den Versionszweig aufzunehmen; es ist in Ordnung wenn andere ihnen die Aufgabe überlassen, so lange jeder versteht, dass sie keiner Obligation unterliegen, die ganze Arbeit zu übernehmen, es sei denn sie haben sich explizit dazu verpflichtet. Wenn die Zeit kommt, die neue Version zu veröffentlichen (siehe später in diesem Kapitel), kümmern sich die Versionsverwalter auch um die logistische Arbeit, die Erstellung der Pakete, das sammeln der digitalen Signaturen, das Hochladen der Pakete, und die öffentliche Bekanntgabe. Die übliche Art, freie Software zu verteilen, ist in Form von Quellcode. Das gilt unabhängig davon, ob die Software normalerweise mit dem Quellcode betrieben wird (d.h. interpretiert werden kann, wie Perl, Python, PHP, usw.) oder vorher kompiliert werden muss (wie C, C++, Java, usw.). Bei kompilierter Software, werden die meisten Nutzer nicht unbedingt selbst die Quellen kompilieren, sondern vorkompilierte binären Paketen installieren wollen (siehe später in diesem Kapitel). Diese binären Pakete leiten sich jedoch trotzdem von der ursprünglichen Quellcode-Distribution ab. Der Sinn der Quellpakete ist, die neue Version eindeutig zu definieren. Wenn das Projekt "Scanley 2.5.0" veröffentlicht, bedeutet das genau genommen, "Die Quellcode-Dateien, die wenn sie kompiliert (falls nötig) und installiert wurden, Scanley 2.5.0 erzeugen". Es gibt einen ziemlich strikten Standard darüber, wie Quellcode-Distributionen auszusehen haben. Man wird ab und zu Abweichungen davon sehen, sie sind aber die Ausnahme, nicht die Regel. Wenn es keinen zwingenden Grund gibt es anders zu machen, sollte sich Ihr Projekt auch an diesen Standard halten. 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. TAR steht für "Tape ARchive", da das TAR Format ein Verzeichnis als einen linearen Datenstrom repräsentiert, ist es ideal für die Speicherung auf Datenbändern. Die gleiche Eigenschaft, macht es zum Standard für die Verteilung von Verzeichnissen als eine einzige Datei. Komprimierte TAR Dateien (auchtarballs) ist relativ einfach. Auf manchen Systemen, kann der tar Befehl von sich aus ein komprimiertes Archiv erstellen; auf anderen, wird eine separate Anwendung benutzt. 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: scanley-2.5.0.tar.gz oder für Windows mit zip Kompression: scanley-2.5.0.zip 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 im Kapitel 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 später in diesem Kapitel), schreiben Sie sie also mit dem Publikum im Hinterkopf. Traditionell, listet eine Datei namens ChangeLog jede Änderung die je an einem Projekt gemach wurde auf, – das heißt, jeden Commit der in das Versionsverwaltungssystem aufgenommen wurde. Es gibt verschiedene Formate für ChangeLog Dateien; die Details der Formate sind an dieser Stelle nicht wichtig, da sie alle die gleichen Informationen beinhalten: Das Datum der Änderung, sein Autor, und eine kurze Zusammenfassung (oder einfach nur den Commit-Kommentar für diese Änderung). Eine CHANGES Datei ist anders. Es ist auch eine Liste von Änderungen, aber nur solche, von denen man denkt, dass sie wichtig genug sind, dass ein bestimmtes Publikum sie sieht, und ohne mit Metadaten wie das genau Datum und der Autor. Um Verwirrung zu vermeiden, vertauschen Sie die Begriffe nicht. Manche Projekte benutzen "NEWS" anstatt von "CHANGES"; obwohl das die mögliche Verwirrung mit "ChangeLog" vermeidet, ist es etwas falsch bezeichnet, da die CHANGES Datei die Änderungs Informationen über alle Versionen enthält, und deshalb eine Menge alte Informationen zusätzlich zu denen ganz oben enthält. ChangeLog Dateien mögen sowieso langsam am verschwinden sein. Sie waren zu einer Zeit hilfreich, als CVS die einzige Wahl für die Versionsverwaltung war, weil Daten über Änderungen nicht leicht aus CVS zu bekommen waren. Bei neueren Systemen können die Daten die ehemals in dem ChangeLog geschrieben wurden, jedoch jederzeit von dem Versionsverwaltungssystem angefordert werden, was es Sinnlos für das Projekt macht, eine Statistik-Datei darüber zu halten – es ist sogar mehr als sinnlos, da die ChangeLog-Datei lediglich die Meldungen, die bereits im Projektarchiv gespeichert sind, duplizieren würde. 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 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 ) 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: scanley-2.5.0.tar.bz2 scanley-2.5.0.tar.gz scanley-2.5.0.zip ...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. Wenn man einen bestimmten Projektnamen nennt, schreiben ihn Leute im allgemeinen groß, wie bei einem Nomen Anmk. des Übersetzers: Im Englischen werden Eigennamen (en. proper noun) auch groß geschrieben und schreiben Abkürzungen groß wenn solche vorhanden sind: "MySQL 5.0", "Scanley 2.5.0", usw. Ob das in dem Paketnamen mit übernommen wird, ist dem Projekt überlassen. Sowohl Scanley-2.5.0.tar.gz als auch scanley-2.5.0.tar.gz wären zum Beispiel in Ordnung (Ich persönlich bevorzuge letzteres, da ich es nicht mag, Leute zu zwingen die Umschalttaste zu drücken, aber eine Menge Projekte veröffentlichen Pakete mit Großschreibung). Das Wichtige ist, dass das Verzeichnis welches beim Entpacken des Tarballs erstellt wird, die gleiche Schreibweise verwendet. Es sollte keine Überraschungen geben: Der Nutzer muss den Namen des Verzeichnisses welches erstellt werden wird, wenn er eine Veröffentlichung entpackt, mit absoluter Genauigkeit vorhersagen können. Wenn Sie eine Vorveröffentlichung machen, ist der Vermerk ein echter Bestandteil der Versionsnummer, nehmen Sie es also mit in den Namen des Pakets auf. Die geordnete Folge von Alpha- und Beta-Versionen, die vorher in diesem Kapitel in verwendet wurde, würde zum Beispiel folgende Paket namen haben: scanley-2.3.0-alpha1.tar.gz scanley-2.3.0-alpha2.tar.gz scanley-2.3.0-beta1.tar.gz scanley-2.3.0-beta2.tar.gz scanley-2.3.0-beta3.tar.gz scanley-2.3.0.tar.gz Das erste würde zum Beispiel zu einem Verzeichnis namens scanley-2.3.0-alpha1 entpacken, dass zweite nach scanley-2.3.0-alpha2, usw. 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 . frei zugänglich. Das ist nicht der einzige Standard, obwohl es einer der am weitesten verbreitetsten ist. Das Build-System Ant () 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 im Kapitel 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 () 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. Wenn der Quellcode tarball von dem stabilisierten Zweig produziert wurde, beginnt der Ablauf sie zu veröffentlichen. Vor der tarball der allgemeinen Öffentlichkeit aber zur Verfügung gestellt wird, sollte es von einer minimalen Menge von Entwicklern getestet und bewilligt werden, üblicherweise drei oder mehr. Die Bewilligung, dreht sich nicht nur darum, die neue Version auf offensichtliche Mängel zu untersuchen, die Entwickler laden den Tarball herunter, machen einen Build und installieren es auf ein sauberes System, lassen die Folge der Regressionstests laufen (siehe ) im Kapitel , und machen ein paar händische Tests. Angenommen, es besteht diese Überprüfungen, sowie irgend welche andere Kriterien für die Veröffentlichung, die das Projekt haben mag, machen die Entwickler eine digitale Signatur von dem tarball mit GnuPG (), PGP (), oder irgend einem anderen Programm welches mit PGP kompatible Signaturen erstellen kann. In den meisten Projekten, benutzen die Entwickler einfach ihre eigenen digitalen Signaturen, anstatt des geteilten Schlüssel vom Projekt und so viele Entwickler die wollen, können es signieren (d.h. es gibt eine Minimum an Entwickler, aber kein Maximum). Je mehr Entwickler signieren, desto mehr Tests unterläuft die neue Version, und desto größer ist die Wahrscheinlichkeit, dass ein sicherheitsbewusster Benutzer ein Pfad des Vertrauens von sich bis zu dem tarball finden kann. Sobald sie bewilligt sind, sollte die neue Version (also, alle tarballs, zip Dateien, sowie alle anderen Formate die veröffentlicht werden) in dem Download-Bereich des Projekts platziert werden, zusammen mit den Signaturen, und MD5/SHA1 Prüfsummen (siehe ). Es gibt verschiedene Standards um das zu machen. Eines ist es, jedes Paket von einer Datei begleiten zu lassen, mit den zugehörigen digitalen Signaturen, und eine weitere Datei mit der Prüfsumme. Wenn das veröffentlichte Paket also scanley-2.5.0.tar.gz ist, platzieren Sie in dem selben Verzeichnis eine Datei scanley-2.5.0.tar.gz.asc mit der digitalen Signatur für diesen tarball, eine weitere Datei scanley-2.5.0.tar.gz.md5 mit seiner MD5 Prüfsumme und optional eine weitere Datei scanley-2.5.0.tar.gz.sha1, mit der SHA1 Prüfsumme. Eine andere Art die Überprüfung zu ermöglichen ist alle Signaturen der veröffentlichten Pakete in eine einzelne Datei zu sammeln scanley-2.5.0.sigs; das gleiche kann mit den Prüfsummen gemacht werden. Es macht nicht wirklich einen Unterschied wie Sie es machen. Halten Sie sich nur an ein einfaches Schema, beschreiben Sie es klar, und seien einheitlich Sie über mehrere Versionen. Der Sinn von all diesen Signaturen und Prüfsummen ist, Nutzern eine Möglichkeit zu geben, zu verifizieren, dass die Kopie die sie erhalten haben nicht böswillig verändert wurde. Die Nutzer werden gleich den Code auf ihren Rechnern laufen lassen – wenn der Code manipuliert wurde, hätte ein Angreifer plötzlich Zugriff auf all ihre Daten. Siehe später in diesem Kapitel für weitere Informationen über Paranoia. Bei wichtigen Veröffentlichungen die viele Änderungen beinhalten, bevorzugen es viele Projekte zuerst release candidates zu veröffentlichen, z.B., scanley-2.5.0-beta1 vor scanley-2.5.0. Der Sinn eines solchen Kandidaten ist den Code weite Tests zu unterwerfen, von es als eine offiziell Version gesegnet wird. Wenn Probleme gefunden werden, werden sie in dem Versionszweig behoben und eine neuer Kandidat wird veröffentlicht (scanley-2.5.0-beta2). Dieser Kreislauf wird so lange weitergeführt, bis keine untragbaren Fehler mehr vorhanden sind, worauf der letzte veröffentlichte Kandidat zur offiziellen Version wird – d.h. der einzige Unterschied zwischen dem letzten Release Candidate und der echten neuen version ist die Entfernung der Kennzeichnung von der Versionsnummer. In den meisten anderen Beziehungen, sollten die Kandidaten wie eine echte finale Version behandelt werde. Die alpha , beta, oder rc Kennzeichnung reicht, um die konservativen Nutzer zu warnen, dass sie auf die echte finale Version warten sollen, und natürlich sollten die E-Mails zur Bekanntgabe darauf hinweisen, dass ihr Sinn das Einholen von Rückmeldungen ist. Davon abgesehen, geben Sie den Kandidaten die gleiche Menge an Sorgfalt wie gewöhnliche neue Versionen. Schließlich wollen Sie, dass Leute sie benutzen, da echte Nutzung die beste Möglichkeit ist, um Fehler zu entdecken, und weil Sie nie wissen, ob ein Release Candidate zur offiziellen Version wird. Eine neue Version bekannt zu geben, ist wie die ankündigung von jedem anderen Ereignis, und sollte die Verfahren die in im Kapitel beschrieben sind benutzen. Es gibt allerdings ein paar spezifische Sachen bei neuen Versionen. Immer wenn Sie die URL zu dem Tarball einer neuen Version herausgeben, geben Sie unbedingt auch die MD5/SHA1 Prüfsummen an und weisen Sie auf die Signatur-Datei hin. Da die Bekanntgabe in meheren Foren stattfindet (Mailverteiler, Ihre Webseite, usw.), können Benutzer die Prüfsummen aus mehreren Quellen bekommen, was die sicherheitsbewussten unter ihnen die zusätzliche Sicherheit gibt, dass die Prüfsummen selber nicht manipuliert wurden. Die Verweise auf die Signaturen macht diese nicht unbedingt sicherer, aber es gibt ihnen (insbesondere denjenigen die das Projekt nicht so nahe verfolgen) die Gewissheit, dass das Projekt die Sicherheit ernst nimmt. In der E-Mail mit der Bekanntgabe, und den Webseiten, die mehr als nur eine kurzen Text über die neue Version enthalten, sollten Sie auch den relevanten Abschnitt aus der CHANGES Datei angeben, damit Leute sehen können, warum es in ihrem Interesse sein könnte eine Aktualisierung durchzuführen. Das ist so wichtig, bei dien Veröffentlichungs Kandidaten wie bei den finalen Versionen; die Existenz von Bugfixes und neuen Funktionen ist wichtig um Leute einen Reitz zu geben, einen neuen Kandidaten auszuprobieren. Schließlich, vergessen Sie es nicht die Entwicklermannschaft zu danken, sowie die Tester und alle anderen die sich die Zeit genommen haben um gute Bug-Meldungen einzureichen. Heben Sie jedoch keinen besonders beim Namen heraus, es sei denn es ist einer für individuell für einen riesigen Anteil Arbeit verantwortlich ist, dessen Wert weithin von jedem in dem Projekt anerkannt ist. Seien Sie nur vorsichtig vor dem rutschigen Abhang der Inflation von Anerkennung (siehe im Kapitel ). Die meisten ausgereiften Projekte pflegen mehrere Versionszweige nebeneinander. Nachdem 1.0.0 erscheint, sollte diese Reihe mit micro Versionen (Fehlerbehebung) 1.0.1, 1.0.2, usw., so lange weiter geführt werden, bis das Projekt sich explizit entscheidet, die Reihe zu beenden. Beachten Sie, dass die Veröffentlichung der 1.1.0 kein ausreichender Grund ist, die 1.0.x Reihe zu beenden. Manche Nutzer aktualisieren zum Beispiel prinzipiell nicht auf die erste Version einer minor oder major Reihe – sie lassen andere die Fehler herausfinden; sagen wir bei der Version 1.1.0 warten sie bis 1.1.1. Das ist nicht zwangsläufig egoistisch (bedenken Sie, dass sie damit auch auf Bugfixes und neue Funktionen verzichten); sie haben sich nur entschieden – aus welchen Gründen auch immer –, bei Aktualisierungen sehr vorsichtig zu sein. Wenn das Projekt von einem ernsthaften Fehler in 1.0.3 erfährt, kurz vor der Veröffentlichung von 1.1.0, wäre es entsprechend hart, den Bugfix nur in 1.1.0 zu stecken, und allen Nutzern der alten 1.0.x Reihe zu sagen, dass Sie aktualisieren sollen. Warum nicht sowohl 1.1.0 als auch 1.0.4 veröffentlichen, damit alle glücklich sind? Nachdem die 1.1.x Reihe gut läuft, können Sie für 1.0.x erklären, dass es am Ende seines Lebenszykluses (en. end of life ) ist. Das sollte offiziell bekannt gegeben werden. Diese Bekanntgabe kann für sich erfolgen, oder im Rahmen der Ankündigung einer neuen 1.1.x Version; wie auch immer Sie sich entscheiden: die Nutzer müssen wissen, dass die alte Reihe ausläuft, damit sie entsprechende Entscheidungen im Bezug auf Aktualisierungen treffen können. Manche Projekte legen einen Fenster fest, indem sie versprechen die vorhergehende Versionsreihe zu pflegen. Im Kontext von Open Source, bedeutet "pflege" (en. "support") die annahme von Bug-Meldungen für diese Reihe, und neue Versionen zu veröffentlichen, wenn bedeutende Fehler gefunden werden. Andere Projekte geben keine definitive Zeitangabe, halten aber ein Auge auf eintreffende Bug-Meldugen um einen Überblick zu behalten, wie viele Personen die alte Reihe noch verwenden. Wenn der Prozentsatz unter einem gewissen Anteil sinkt, erklären sie für die Reihe, dass es am ende seines Lebens ist und hören auf es zu pflegen. Sorgen Sie bei jeder neuen Version dafür, dass ein target version (de. Zielversion) oder target milestone (de. Ziel-Meilenstein) in dem Bugtracker zur Verfügung steht, damit Personen die Bugs finden, ihre Meldungen unter der richtig Version einordnen können. Vergessen Sie nicht auch einen Ziel namens "development" (de. Entwicklung) oder "latest" (de. aktuelle) für den neusten Quellcode zu haben, da manche – nicht nur die aktiven Entwickler – oft den offiziellen Versionen voraus bleiben werden. Die meisten Details über die Handhabung von Sicherheitslücken wurden in im Kapitel behandelt, es gibt aber ein paar besondere Details, die es für Sicherheits-Updates zu besprechen gibt. Ein Sicherheitsupdate ist eine Version die nur gemacht wird, um eine Sicherheitslücke zu schließen. Der Code, welcher den Bug behebt, kann nicht veröffentlicht werden, bis die neue Version zur Verfügung steht, was nicht nur bedeutet, dass die Fixes nicht zum Projektarchiv committet werden können, bis zum Tag der Veröffentlichung, sondern dass die Version nicht öffentlich getestet weden kann, bis sie freigegeben wird. Die Entwickler können den Fix offensichtlich unter sich untersuchen, und die neue Version privat testen, aber breites Testen unter realen Bedingungen ist nicht möglich. Aufgrund dieses Mangel an Tests, sollte ein Sicherheits-Update immer aus einer bereits herausgegebenen Version bestehen, ergänzt duch die Fixes für die Sicherheitslücke ohne sonstige Änderungen. Denn je mehr Änderungen Sie in einer Version veröffentlichen, desto wahrscheinlicher ist es, dass eine von ihnen einen neuen Fehler verursachen wird, vieleicht sogar eine neue Sicherheitslücke! In dieser Hinsicht konservativ zu sein, kommt auch den Administratoren entgegen, die das Sicherheitsupdate einspielen werden, deren Richtlinien im Bezug auf Aktualisierungen es aber nicht zulassen, zur gleichen Zeit sonstige Änderungen einspielen. Ein Sicherheitsupdate zu erstellen, ist manchmal auch mit ein wenig Täuschung verbunden. Das Projekt könnte zum Beispiel an der Version 1.1.3 arbeiten, für die bestimmte Bugfixes an 1.1.2 bereits öffentlich in Aussicht gestellt wurden, und in diesem Moment trifft die Sicherheitsmeldung ein. Die Entwickler können natürlich nicht über das Sicherheitsproblem reden, bis sie den Fix zur Verfügung stellen; bis dahin müssen sie weiter öffentlich so reden, als wäre 1.1.3 das, was die ganze Zeit geplant war. Wenn 1.1.3 aber wirklich erscheint, wird es sich von 1.1.2 nur durch die Sicherheitsfixes unterscheiden, und alles andere wird auf die Version 1.1.4 aufgeschoben (die jetzt natürlich auch den Sicherheitsfix beinhalten wird, genau so wie alle zukünftigen Versionen). Sie könnten eine weitere Komponente zu der bestehenden Version hinzufügen, welche darauf hindeutet, dass nur Sicherheitsänderungen enthalten sind. Zum Beispiel könnte man alleine an den Zahlen erkennen, dass 1.1.2.1 ein Sicherheitsupdate zu 1.1.2 ist, und es würde deutlich, dass jede "höhere" Version (d.h. 1.1.3, 1.2.0, usw.) die gleichen Sicherheitsfixes beinhaltet. Für diejenigen die es wissen, teilt dieses System eine Menge Informationen mit. Andererseits kann es für diejenigen die das Projekt nicht so nah verfolgenein, ein wenig verwirrend sein, die meiste Zeit ein Drei-Komponenten-System zu sehen, in das gelegentlich vierstellige Versionsnummen eingestreut sind. Die meisten Projekte die ich mir angeschaut habe, bevorzugen Konsistenz und benutzen einfach die nächste geplante Versionsnummer für Sicherheitsupdates, selbst wenn das bedeutet, andere geplante Versionen um eins zu verschieben. Parallele Versionen gleichzeitig zu pflegen, hat Auswirkungen darauf, wie die tägliche Entwicklung vonstatten geht. Es macht insbesondere etwas praktisch zur Pflicht, was sowieso empfohlen wird: Jeder Commit sollte eine einzige logische Änderung sein, und nicht zusammenhängende Änderungen sollten niemals in dem gleichen Commit gemacht werden. Wenn eine Änderung zu groß ist oder zu störend ist, um sie in einem Commit zu machen, verteilen Sie es über N Commits, wobei jeder Commit eine wohl aufgeteilte Untermenge der gesamten Änderung ist, und nichts beinhaltet, das keinen Bezug zu der Gesamtänderung hat. Hier ist ein Beispiel eines schlecht überdachten Commit: ------------------------------------------------------------------------ r6228 | hmustermann | 2004-06-30 22:13:07 -0500 (Wed, 30 Jun 2004) | 8 Zeilen Fehler #1729 behoben: Sorge dafür, dass die Indexierung dem Nutzer elegant eine Warnung gibt, wenn eine Datei die sich ändert, indexiert wird. * ui/repl.py (ChangingFile): Neue Ausnahme-Klasse. (DoIndex): Verarbeite die neue Ausnahme. * indexer/index.py (FollowStream): Werfen einer neuen Ausnahme, wenn eine Datei sich wärend der Indexierung ändert. (BuildDir): In einem anderen Zusammenhang, Entfernung von veralteten Komentaren, Neuformatierung vom Code, und Behebung der Fehlerprüfung wenn ein Verzeichnis erzeugt wird. Andere nicht verwandte Aufräumarbeiten: * www/index.html: Ein paar Vertipper behoben, das Datum der nächsten Version gesetzt. ------------------------------------------------------------------------ Das Problem dabei wird offensichtlich, wenn jemand die Änderung der Fehlerprüfung in BuildDir für einen bald anstehende Micro-Version in einen anderen Zweig portieren muss. Der Portierende will nicht irgendwelche der anderen Änderungen – vielleicht wurde der Fix für die Meldung #1729 überhaupt nicht für den Stabilen Zweig genemigt, und die Verbesserungen an index.html wären dort einfach irrelevant. Mittels der Merge-Funktion kann er aber die Änderung an BuildDir nicht einfach übernehmen, weil dem Versionsverwaltungssytem gesagt wurde, dass diese Änderung mit den anderen nicht zusammenhängenden Dingen logisch gruppiert ist. Tatsächlich würde das Problem sogar vor dem Merge offensichtlich werden. Alleine schon die Auflistung der Änderung zur Abstimmung würde problematisch werden: statt nur die Revisionsnummer anzugeben, müsste der Antragsteller einen besonderen Patch oder Änderungszweig erstellen, nur um den Anteil der Änderung, welcher vorgeschlagen wird, zu isolieren. Das wäre eine Menge Arbeit, unter der die Anderen leiden müssten, und alles nur weil der ursprüngliche Committer keine Lust hatte, die Änderungen logisch zu gruppieren. Dieser Commit hätte in Wirklichkeit sogar aus vier einzelnen Commits bestehen sollen: Einen um den Fehler #1729 zu beheben, einen weiteren um die veralteten Komentare zu entfernen und den Code in BuildDir neu zu formatieren, noch einen für die Fehlerprüfung in BuildDir , und zuletzt einen, um die Datei index.html zu überarbeiten. Die Stabilisierung der neuen Version ist natürlich nicht der einzige Grund für den Wunsch danach, dass jeder Commit eine einzige logische Änderung ist. Psychologisch ist ein semantisch eindeitiger Commit leichter zu überprüfen und leichter rückgängig zu machen falls nötig (in manchen Versionsverwaltungsystemen ist sowieso eine besondere Art von Merge, wenn man etwas rückgängig macht). Etwas vorausschauende Disziplin der Beteiligten kann dem Projekt später eine Menge Kopfschmerzen ersparen. Ein Bereich, in dem Open-Source-Projekte sich historisch von proprietären Projekten differenziert haben, ist die Planung neuer Versionen. Proprietäre Projekte haben gewöhnlich strengere Fristen. Manchmal weil einem Kunden zu einem bestimmten Datum ein Upgrade versprochen wurde, da die neue Version mit einer anderen Absicht aus Marketing-Gründen koordiniert werden muss, oder weil die Risikokapitalgeber die in die ganze Sache investiert haben, Ergebnisse sehen müssen, bevor sie weitere Finanzierungsmittel hineinstecken. Freie Software-Projekte hingegen waren bis zuletzt meistens durch Amateurhaftigkeit im wörtlichsten Sinne motiviert: Sie wurden aus Liebe geschrieben. Keiner hatte ein Drang, etwas zu veröffentlichen, bevor alle Funktionen fertig waren, und warum sollten sie auch? Es war ja nicht so, dass hier der Arbeitsplatz von jemandem auf den Spiel stand. Heutzutage werden viele Open-Source-Projekte durch Firmen finanziert, und werden entsprechen mehr und mehr durch fristbewusste Unternehmenskulturen beeinflusst. Das mag in vielerlei Hinsicht etwas Gutes sein, kann aber auch Konflikte verursachen zwischen den Prioritäten der Entwickler, die bezahlt werden, von denen der Entwickler, die ihre Zeit freiwillig investieren. Diese Konflikte kommen oft bei der Frage auf, wann und wie die neuen Versionen geplant werden. Die angestellten Entwickler, die unter Druck stehen, werden natürlich einfach irgendein Datum wählen wollen, an dem die Veröffentlichung stattfinden soll, und alle anderen Aktivitäten entsprechend einordnen. Die freiwilligen Entwickler können jedoch andere Pläne haben – vieleicht Funktionen, die sie fertig stellen wollen, oder Tests, die sie gemacht haben wollen – worauf ihrer Meinung nach die Veröffentlichung warten soll. Es gibt keine allgemeine Lösung für dieses Problem, außer natürlich zu diskutieren und Kompromisse zu schließen. Sie können jedoch den Grad und die Menge an Reibung die verursacht wird minimieren, indem Sie die Existenz der vorgeschlagenen Version von dem Datum entkoppeln, an dem sie veröffentlicht werden soll. Das heißt, versuchen Sie die Diskussion in Richtung des Themas zu lenken, welche Versionen das Projekt in der nächsten bis mittelfristigen Zeit machen wird, und welche Funktionen sie haben werden, zunächst ohne über Termine zu sprechen, abgesehen von groben Schätzungen mit einer Menge Spielraum. Einen alternativen Ansatz können Sie in Martin Michlmayrs Dr. phil. Dissertation nachlesen Quality Improvement in Volunteer Free and Open Source Software Projects: Exploring the Impact of Release Management (). Sie behandelt einen zeitbasierten im Gegensatz zu einem Feature-basierten Herausgabe-Prozess für umfangreiche free Software-Projekte. Michlmayr hielt auch einen Vortrag bei Google zu diesem Thema, verfügbar als Video unter . Indem Sie frühzeitig den Funktionsumfang festlegen, reduzieren Sie die Komplexität der Diskussion, die sich um irgend eine bestimmte Version dreht, und verbessern dadurch die Berechenbarkeit. Das verursacht auch eine Art träger Voreinstellung, auf Leute, die vorschlagen die Definition einer Version mit neuen Funktionen oder andere Komplikationen zu erweitern. Wenn der Inhalt der Version relativ gut definiert ist, obliegt die Rechtfertigungspflicht für Erweiterungen dem Vorschlagenden, auch wenn das Datum der Version noch nicht festgelegt wurde. In seiner mehrbändigen Thomas-Jefferson-Biographie, Jefferson and His Time, erzählt Dumas Malone die Geschichte, wie Jefferson das erste Treffen handhabte, das abgehalten wurde, um über die Organization der zukunftigen Universität von Virginia zu entscheiden. Die Universität war von Anfang an die Idee von Jefferson gewesen, aber (wie es überall der Fall ist, nicht nur in Open-Source-Projekten) waren sehr schnell viele andere Parteien an Bord, jede mit eigenen Interessen und Anliegen. Als sie sich zu diesem ersten Treffen versammelten, um alles auszuarbeiten, erschien Jefferson mit minuziös vorbereiteten Bauplänen, detaillierten Budgets für die Konstruktion und den Betrieb, einem Lehrplanentwurf, und den Namen der einzelnen Fakultäten die er aus Europa importieren wollte. Kein anderer im Raum war nur annähernd so gut vorbereitet; die Gruppe musste im wesentlichen vor der Vision von Jefferson kapitulieren und die Universität wurde letztlich mehr oder weniger entsprechend seinen Plänen gegründet. Die Tatsachen, dass die Konstruktion weit über sein Budget ging, und viele seiner Ideen aus verschieden Gründen am Ende nicht funktionierten, waren Dinge, von denen Jefferson wahrscheinlich anfangs genau wusste, dass sie passieren würden. Sein Vorhaben war strategisch: Bei der Versammlung mit etwas derart Stichhaltigem aufzutauchen, dass jeder ander in die Rolle verfallen müsste, lediglich Änderungen daran vorzuschlagen, damit die allgemeine Gestalt, und dadurch der Terminplan des Projekts, ungefähr so bliebe, wie er es wollte. Im Falle eines freien Software-Projekts, gibt es kein einzelnes "Treffen", sondern stattdessen eine Reihe kleiner Vorschläge die meistens durch den Bugtracker gemacht werden. Wenn Sie aber von Anfang an etwas Ansehen im Projekt haben, und anfangen verschiedene Funktionen, Verbesserungen, und Fehler für bestimmte Versionen im Bugtracker festzulegen, entsprechend irgend einem erklärten Gesamtplan, werden die Leute meistens mitmachen. Wenn Sie erst alles mehr oder weniger so ausgelegt haben, wie Sie es wollen, werden die Unterhaltungen über echte Termine für neue Versionen sehr viel glatter verlaufen. Es ist natürlich äußerst wichtig, dass Sie niemals irgend eine einzelne Entscheidung als in Stein gemeißelt präsentieren. Zeigen Sie in den Kommentaren anlässlich der Zuordnung von Bugs zu bestimmten Versionen wenn möglich stets Bereitschaft zu Diskussionen, Meinungsverschiedenheiten und die allgemeine Bereitschaft, überredet zu werden. Üben Sie niemals Kontrolle alleine um ihrer Ausübung willen: Je mehr andere sich an der Planung einer neuen Version beteiligen (siehe im Kapitel ), desto leichter wird es sein sie zu überreden, Ihre Prioritäten bei Angelegenheiten zu teilen, die Ihnen wirklich wichtig sind. Die andere Möglichkeit, Spannungen bei der Planung neuer Versionen des Projekts zu veringern ist, relativ häufig zu veröffentlichen. Wenn zwischen den Veröffentlichungen eine lange Zeit liegt, wird die Bedeutung von jeder einzenen in den Köpfen allern vergrößert; die Leute sind um so mehr betrübt, wenn ihr Code es nicht hinein schafft, weil sie wissen wie lange es dauern könnte, bis die nächste Gelegenheit kommt. Abhängig von der Komplexität des Ablaufs bei einer neuen Version und der Natur Ihres Projekts, liegt die richtige Zeit zwischen den einzelnen Veröffentlichungen gewöhnlich irgendwo zwischen drei und sechs Monaten, obwohl in den Stabilen Zweigen Micro-Veröffentlichungen ein wenig schneller geschehen können, wenn dafür Bedarf besteht.