055.2 Lektion 1

Stabilität ist eine wichtige Eigenschaft, die Benutzer von Software erwarten. Die erste Frage, die sich viele stellen, wenn sie von einer neuen Version hören, lautet entsprechend: “Wie stabil ist sie?” Mit anderen Worten: Funktioniert sie zuverlässig, oder stürzt sie ab? Beschädigt sie Daten oder liefert sie falsche Ergebnisse?

Stabilität kann auf einem Spektrum gemessen werden, und viele setzen Software auch gerne ein, wenn sie noch einige Fehler enthält. Aber Entwicklungsteams neigen dazu, die Dinge einfach zu halten, und unterscheiden binär stable und unstable Versionen.

Stabilität bezieht sich sowohl auf die Fehleranfälligkeit der Software als auch auf sichtbare Veränderungen für Außenstehende bzw. Benutzer. Entwickler könnten eine Version einer Softwarebibliothek als unstable betrachten, weil Funktionen geändert wurden, die Programmierer aufrufen (mit der Folge, dass die Entwickler ihre Software für die nächste Version möglicherweise umschreiben müssen). Die Software könnte aber auch aus Benutzersicht instabil sein, weil Entwickler eine Funktion entfernt haben.

Gibt es Gründe, eine unstable Version zu veröffentlichen? Ja. Sie ist wertvoll, weil Benutzer neue Funktionen schon in einer frühen Projektphase ausprobieren und auf Fehler testen können.

Die meisten Projekte geben sehr frühe Versionen der Software für wichtige Kunden zum Testen frei, die sogenannten Alpha Releases. Natürlich sollte man diese Releases nicht in produktiven Arbeitsumgebungen einsetzen — sie sind nur zum Testen gedacht. Tester sollten Alpha Releases auf Rechnern außerhalb der Arbeitsumgebung laufen lassen, da Fehler in diesen Releases die auf dem Computer gespeicherten Daten beschädigen könnten.

Steht die Software nach Ansicht der Entwickler kurz davor, als stabil zu gelten, veröffentlicht das Projekt normalerweise eine weitere Testversion, die als Beta Release bezeichnet wird. Diese sollte immer noch nicht auf Produktivsystemen eingesetzt werden, sondern ausschließlich für Tests.

Sowohl bei Alpha- als auch bei Beta-Versionen nutzen Entwickler standardisierte Verfahren, um Fehler zu melden und den Fortschritt bei der Fehlerbehebung zu verfolgen.

Bei manchen Projekten gibt es zwischen der Beta- und der stable Version eine weitere Phase, in der die Entwickler alle Fehler behoben haben und das Produkt als fertig erachten. Sie bezeichnen die Version als Release Candidate und stellen sie ausgewählten Kunden oder Interessenten zur Verfügung, damit diese den Einsatz neuer Funktionen planen können.

Es ist wichtig, dass Benutzer neue Funktionen ausprobieren und Feedback dazu geben, bevor die Entwickler die Schnittstellen fertigstellen und neue Funktionen aufwendig stabilisieren.

Die meisten Projekte bemühen sich um Abwärtskompatibilität (Backward Compatibility): sie versuchen, Funktionen, die in älteren Versionen vorhanden waren, zu erhalten. Kompatibilität kann auf mehreren Ebenen bestehen: Indem Entwickler beispielsweise Abwärtskompatibilität für die Programmierschnittstelle von Anwendungen (API) erhalten, stellen sie sicher, dass alter Quellcode weiterhin funktionieren kann, auch wenn er möglicherweise neu kompiliert werden muss. Wenn Hardwarehersteller oder Betriebssystementwickler Abwärtskompatibilität für das Application Binary Interface (ABI) erhalten, sorgen sie dafür, dass alte ausführbare Dateien auf neuen Versionen der Hardware laufen.

Wir werden uns später ansehen, wie Projekte mit fehlender Abwärtskompatibilität umgehen, wenn sie sich also entscheiden, alte Schnittstellen für die neuen Funktionen oder Umgebungen nicht mehr unterstützen.

Idealerweise wird Software immer besser, wenn Entwickler Probleme entdecken und beheben. Aber mit der Zeit können Funktionen aufgrund von Änderungen in der Softwareumgebung nicht mehr funktionieren. Außerdem werden neue Fehler entdeckt, die zuvor nicht aufgefallen waren.

Neue Versionen kombinieren oft Sicherheits- und Fehlerkorrekturen mit neuen Funktionen. Vielleicht möchten Sie die neuen Funktionen gar nicht haben — vielleicht bevorzugen Sie sogar eine alte Funktion, die die Entwickler entfernt haben, um Platz für neue Funktionen zu schaffen. Aber die meisten Benutzer aktualisieren auf die neue Version für die Sicherheitskorrekturen, die sie vor Angriffen schützen.

Manche nutzen alte Softwareversionen weiter und verzichten auf ein Upgrade, weil die neue Version in ihrer Umgebung anders oder gar nicht funktioniert. Wenn Unternehmen Geld für Upgrades verlangen, ist das für manche Kunden ebenfalls ein Grund, kein Upgrade durchzuführen; bei Open Source muss man für Upgrades allerdings selten etwas zahlen.

Entwickler kommen den Benutzern alter Versionen nach Möglichkeit entgegen, indem sie Fehler in den alten Versionen beheben, ohne die neuen Funktionen hinzuzufügen, die die Software möglicherweise instabil machen. Natürlich können Entwickler dies nicht unbegrenzt leisten; irgendwann werden sie eine alte Version nicht mehr reparieren und die Benutzer auffordern, entweder ein Upgrade durchzuführen oder die Korrekturen selbst vorzunehmen.

Das Beheben von Fehlern und Sicherheitslücken wird als Support (Unterstützung) für die Software bezeichnet. Er unterscheidet sich von dem Support, den Helpdesks und andere anbieten, um Benutzer beim Einsatz der Software zu unterstützen. Was das Versionsmanagement angeht, so ist eine unterstützte Version eine, für die die Entwickler Fehlerkorrekturen zusagen, während sie dies bei einer nicht unterstützten Version nicht (mehr) tun.

Beachten Sie, dass “Support” meist für Software angeboten wird, die von Unternehmen oder großen Organisationen entwickelt wird. Kleinere Open-Source-Projekte, die stark vom Einsatz Freiwilliger abhängig sind, tun oft ihr bestes, um Fehler zu beheben und neue Versionen herauszubringen, ohne dies garantieren zu können. Sie sehen oft auch keine Notwendigkeit, alte Versionen zu reparieren; da der Code Open Source ist, können Benutzer, die nicht aktualisieren wollen, jemanden dafür bezahlen, eine alte Version zu reparieren.

Wird Support angeboten, veröffentlichen die Entwickler einen Zeitplan, der angibt, wie lange sie eine Version unterstützen werden. Das Datum, zu dem der Support endet, wird als End of Life (EOL) der Software bezeichnet. Benutzer können die alte Version bis zum EOL einsetzen und erwarten, dass Fehler behoben werden; nach dem EOL müssen sie jedoch ein Upgrade durchführen oder das Risiko tragen.

Große Projekte, wie beispielsweise die Debian-Distribution von GNU/Linux, bieten Versionen mit Long Term Support (LTS) an. Das bedeutet, dass die Entwickler eine bestimmte Anzahl von Jahren Fehler beheben. Kunden, die großen Wert auf Stabilität legen, scheuen sich vielleicht, Softwareversionen zu installieren, die zahlreiche Änderungen enthalten; die Änderungen könnten Prozesse unterbrechen, auf die sich die Kunden verlassen. Solche Kunden, vor allem große Unternehmen und Institutionen, schätzen die Sicherheit von LTS-Versionen.

Entwickler versuchen, weit im Voraus festzulegen, welche Änderungen sie an einem Produkt vornehmen wollen. Im kommerziellen Umfeld sprechen sie mit ihren Kollegen vom Marketing, die filtern und zusammenfassen, was ihre Kunden wünschen. Open-Source-Projekte hängen eher von den Ideen ab, die von Entwicklern und Benutzern eingereicht und in einer Datenbank, dem Issue Tracker, erfasst werden. Wenn Benutzer die Behebung eines Fehlers oder eine neue Funktion wünschen, erstellen sie ein sogenanntes Issue. Die Entwickler setzen dann Prioritäten für die Änderungen und entscheiden, wer sich um welches Issue kümmert.

Wie aber werden Änderungen ausgewählt und priorisiert? Das kann ein ungeordneter Prozess sein, aber gute Projektmanager in Open-Source-Projekten ermutigen zu breitem Input und stellen gleichzeitig sicher, dass Entscheidungen getroffen werden. Einige Projekte halten sogar Konferenzen ab, auf denen die Teilnehmer die Prioritäten diskutieren.

Eine öffentliche Roadmap, also ein Fahrplan für die geplanten Änderungen, legt die Schritte fest. Sie kann viele Versionen und Jahre in die Zukunft abbilden. Jeder Schritt wird als Milestone (Meilenstein) bezeichnet und kann mit einem Zieldatum verbunden sein.

Es gibt grundsätzlich zwei Ansätze, Releases zu planen: zeitbasiert oder funktionsbasiert. Ein Projekt kann ein Release in regelmäßigen Abständen — zum Beispiel alle sechs Monate — planen und alles aufnehmen, was zu diesem Zeitpunkt fertig ist. Alternativ kann das Projekt bestimmte Funktionen für ein Release vorsehen, und den Entwicklern so viel Zeit lassen, wie sie für die Fertigstellung dieser Funktionen benötigen.

Wenn der Zeitpunkt der Veröffentlichung näher rückt, legt der Release Manager die Termine für die Alpha-, die Beta- und die stabile Version fest. Die Teammitglieder prüfen regelmäßig die Fehlerberichte und versuchen, ihre Arbeit so zu planen, dass sie die Meilensteine einhalten.

Um eine neue Version fertigzustellen, muss ein Projekt ab einem gewissen Punkt aufhören, Ideen für neue Funktionen anzunehmen, und sich darauf konzentrieren, die vorhandenen Funktionen korrekt umzusetzen. Dieser Zeitpunkt wird als Feature Freeze bezeichnet.