„Stable" klingt nach einer geprüften Eigenschaft. Tatsächlich ist es meist nur eine Selbstauskunft der Maintainer – keine Aussage über Qualität, sondern eine Behauptung über den eigenen Code.
Das wird besonders deutlich an einer unauffälligen Composer-Einstellung, die in fast jeder composer.json steht:
{
"minimum-stability": "stable"
}
Composer unterscheidet Versionen nach einem reinen Namensschema:
1.0.0-alpha
1.0.0-beta
1.0.0-RC1
1.0.0
„Stable" bedeutet hier: kein Alpha, kein Beta, kein Release Candidate. Jede Version ohne einen solchen Suffix gilt als stabil – v1.0.0, v1.2.3, v2.0.0, alle gleichermaßen. Composer trifft damit keine Aussage über Qualität. Es trifft eine Aussage über eine Zeichenkette im Versionsnamen.
Das ist bemerkenswert, wenn man bedenkt wie zentral Composer im PHP-Ökosystem ist. Selbst eines der wichtigsten Werkzeuge der Sprache behandelt Stabilität als Versionsmetadatum, nicht als Qualitätsmerkmal. Wenn schon die Infrastruktur „stable" so versteht, ist es kein Wunder, dass auch Projekte selbst den Begriff sehr unterschiedlich auslegen.
Das ist der Kern des Problems: jeder darf seine eigene Software „stable" nennen. Die Frage ist nicht, ob das Label vergeben wurde. Die Frage ist, wer es vergeben hat und wonach.
Was Entwickler unter „stable" erwarten
Wenn Entwickler das Wort lesen, denken sie selten an Composers Namensschema. Sie denken an eine Reihe ungeschriebener Versprechen.
API-Stabilität. Aufrufender Code wie $mailer->send($message); soll über Patch- und Minor-Releases hinweg weiter funktionieren. Breaking Changes werden vermieden oder zumindest sauber versioniert angekündigt.
Überschaubare bekannte Fehler. Bugs gibt es immer. Aber keine bekannten Showstopper – Datenverlust, Abstürze, kaputte Migrationen.
Ausreichende Dokumentation. Nicht perfekt, aber genug um das System produktiv einzusetzen ohne den Quellcode lesen zu müssen.
Existierende Upgrade-Pfade. Changelogs, Release Notes, im Idealfall Migrationsanleitungen für größere Versionssprünge.
Laufende Wartung. Wenn kritische Fehler auftauchen, werden sie behoben – als erkennbarer, laufender Prozess.
Keine dieser fünf Erwartungen steht im Wort „stable" selbst. Sie werden nur stillschweigend mitgedacht – und genau das wird zum Problem, sobald Maintainer und Nutzer unterschiedliche Erwartungen mitdenken.
Eine echte Debatte: das LimeSurvey-Forum
Diese Lücke zwischen Begriff und Erwartung ist keine Theorie. Im LimeSurvey-Forum gibt es einen Thread aus dem Jahr 2018, der sie exakt durchspielt – mit echten Beteiligten, echten Zitaten, einem echten Bug als Beweisstück.
Der Thread-Eröffner bringt die Kernbeobachtung auf den Punkt: die meisten Nutzer verstehen unter „stable" praktisch bugfreie Software. Die Entwickler dagegen verstehen darunter etwas anderes – dass sich Funktionalität, Struktur und API seit dem letzten Release nicht mehr geändert haben. Zwei Definitionen, ein Wort.
Sein Vorschlag war ein Stufenmodell: BETA für Software die noch nicht feature-complete ist, RELEASE für feature-complete aber nicht vollständig getestete Software, STABLE für feature-complete mit längerer öffentlicher Erprobung, und LTS als oberste Stufe mit langfristiger Unterstützung. Ein durchdachter Versuch, Erwartung und Wortwahl wieder zusammenzubringen.
Ein anderer Beteiligter, der hauptberuflich mit Umfragesoftware für Kunden arbeitet, macht klar warum das mehr als Begriffsklauberei ist. Bei einer Forschungsumfrage mit knappem Erhebungsfenster ist ein Bug der den Datenexport verhindert kein kleiner Fehler, sondern ein Geschäftsrisiko. Wie erklärt man einem Kunden, dass die Auswertung zwei Wochen verspätet kommt, weil die Ergebnisse zwar vorliegen, aber nicht exportierbar sind? Seine Schlussfolgerung: er setzt die Software für genau diese Art von Projekten deshalb gar nicht ein.
Die Pointe des Threads liefert sich fast von selbst. Während die Diskussion läuft, verteidigt ein Beteiligter die aktuelle Version als „fast so stabil wie die vorherige Langzeitversion" – im selben Atemzug wird ein Bug im Expression Manager besprochen, der bestimmte Fragetypen unbenutzbar macht. Er stuft den Bug herunter: betrifft ja nur einen speziellen Fragetyp. Die Antwort darauf trifft den Kern der ganzen Debatte: für jemanden der genau diesen Fragetyp in seiner Umfrage braucht, ist es trotzdem ein Showstopper.
Stabilität ist kontextabhängig. Ein Fehler im Datenexport mag für viele Anwender bedeutungslos sein. Für jemanden, der genau diesen Export morgen einem Kunden liefern muss, ist derselbe Fehler ein Showstopper. Die Schwere eines Bugs lässt sich nicht von der Anzahl der betroffenen Codepfade ableiten, sondern nur davon, ob er die Arbeit eines konkreten Nutzers verhindert. „Stable" ist also nicht nur die falsche Frage in Bezug auf die Definition – sie ist auch die falsche Frage ohne ein Subjekt. Stabil für wen?
Zwei verschiedene Stabilitäten
Der Forenthread zeigt im Grunde zwei unterschiedliche Bedeutungen die unter demselben Wort verhandelt werden.
Release-Stabilität ist das was Maintainer meist meinen: keine Breaking Changes, reproduzierbare Releases, eingehaltenes Semantic Versioning. Eine Aussage über den Umgang mit Versionen.
Betriebsstabilität ist das was Nutzer meist meinen: keine Ausfälle, keine Datenverluste, vorhersehbares Verhalten im produktiven Einsatz. Eine Aussage über das tatsächliche Verhalten der Software im Alltag.
Beide Bedeutungen sind legitim. Ein Projekt kann hervorragende Release-Stabilität haben – strikte SemVer-Disziplin, klare Changelogs – und trotzdem im Betrieb einen Showstopper-Bug enthalten der für bestimmte Nutzer alles blockiert. Genau das passiert im LimeSurvey-Beispiel: die Diskussion über „wie stabil ist 3.x" bewegt sich ständig zwischen diesen beiden Ebenen, ohne dass es jemandem auffällt.
Wer „stable" liest, sollte sich deshalb fragen welche der beiden Bedeutungen gerade gemeint ist. Es ist selten dieselbe.
Ein Gedankenexperiment
Um den Unterschied noch schärfer zu machen, hilft ein einfacher Vergleich zwischen zwei fiktiven Projekten, beide offiziell als „stable" markiert.
Projekt A hat fünfzehn Nutzer, 95 Prozent Testabdeckung, hält sich strikt an Semantic Versioning, läuft mit CI/CD-Pipeline und hat klar definierte öffentliche APIs. Starke Release-Stabilität.
Projekt B hat fünftausend Nutzer, mäßige Testabdeckung, ein inkonsequent eingehaltenes SemVer mit gelegentlichen kleinen Inkonsistenzen, aber wenige Regressionen und läuft seit Jahren produktiv im Einsatz. Schwächere Release-Disziplin als Projekt A – aber dadurch nicht automatisch weniger zuverlässig im Alltag, einfach weil es lange genug existiert und die häufigsten Pfade ausgiebig durchlaufen wurden.
Beide dürfen sich „stable" nennen. Aber sie meinen unterschiedliche Dinge damit, und keines der beiden Labels verrät das von außen.
Stabilität ist primär eine Eigenschaft des Prozesses
Eine verbreitete Annahme ist, Stabilität sei eine Eigenschaft des Codes. Das greift zu kurz. Stabil wird Software nicht durch Code allein, sondern durch das was um den Code herum passiert: Tests, Release-Prozesse, Monitoring, Bugfix-Zyklen, laufende Wartung.
Viele instabile Systeme enthalten technisch hervorragenden Code, der nur niemand pflegt. Viele stabile Systeme enthalten Code der einem Code-Review nicht standhalten würde, laufen aber seit Jahren zuverlässig, weil ein eingespielter Prozess jeden auftretenden Fehler schnell findet und behebt. Stabilität entsteht aus der Wiederholung dieses Prozesses, nicht aus der Eleganz einer einzelnen Codezeile.
Die bessere Frage
Wenn ich heute ein Framework oder eine Bibliothek evaluiere und in der Dokumentation steht „ist stable", ist meine erste Reaktion nicht Zustimmung. Es ist eine Anschlussfrage: woran macht ihr das fest?
Das ist derselbe Sprung wie von „Ist die Software sicher?" zu „Wie weist ihr Sicherheit nach?" Die zweite Formulierung ist in beiden Fällen die interessantere, weil sie eine überprüfbare Antwort verlangt statt einer Behauptung.
Konkret helfen Fragen wie: Wird Semantic Versioning eingehalten, und zwar nachweislich über mehrere Releases? Existiert eine klar definierte öffentliche API? Wie hoch ist die Testabdeckung, durchgesetzt durch eine CI/CD-Pipeline? Gibt es eine erkennbare Upgrade-Strategie? Wie reagiert das Projekt auf gemeldete Bugs – in Tagen, oder in Monaten? Und nicht zuletzt: ist von Release-Stabilität oder von Betriebsstabilität die Rede – und für welche Art von Nutzung?
Keine einzelne dieser Fragen ersetzt das Wort „stable". Zusammen ersetzen sie es aber durch etwas Belastbareres: einen Prozess den man beobachten und nachprüfen kann, statt eine Behauptung der man vertrauen muss.