Asymmetrische Modernisierung

Wer sich mit der composer.json im develop-major-Branch von LimeSurvey beschäftigt, findet dort folgendes Detail:

"config": {
    "vendor-dir": "vendor",
    "bin-dir": "vendor/bin",
    "platform": {
        "php": "8.1.29"
    }
}

Gleichzeitig fehlt eine explizite PHP-Anforderung:

"require": {
    "php": ">=8.1"
}

Auf den ersten Blick ein kleines technisches Detail. Tatsächlich illustriert diese Konstellation ein Muster, das man in jedem langlebigen PHP-System findet – und das erklärungsbedürftiger ist als es aussieht.

Was config.platform.php sagt

Die platform-Konfiguration sorgt dafür, dass Composer die Dependency-Auflösung gegen eine festgelegte PHP-Version durchführt – unabhängig davon was tatsächlich auf dem System läuft. Reproduzierbare Builds, konsistente Paketversionen, keine Überraschungen zwischen Entwicklungs- und Produktionsumgebung. Das ist vernünftig.

Was fehlt, ist das explizite "php": ">=8.1" in require. Das bedeutet: Composer weiss intern von PHP 8.1 – aber das Paket kommuniziert diese Anforderung nicht nach aussen. Die Mindestanforderung wird damit implizit über Dependencies statt explizit über das Projekt selbst kommuniziert.

Das ist kein Bug. Es ist ein Symptom. Und es bekommt ein zusätzliches Gewicht wenn man sich den aktuellen PHP-Support-Status ansieht:

PHP 8.1 ist seit dem 31. Dezember 2025 End of Life – keine Security Patches mehr, keine Bug Fixes. LimeSurvey 7 konfiguriert seine Dependency-Auflösung gegen eine Version die seit vier Monaten keine Sicherheitsupdates mehr erhält. Ein explizites "php": ">=8.1" in require wäre heute bereits eine Empfehlung auf eine EOL-Version. Realistisch wäre ">=8.2" als Minimum – und 8.3 als eigentliches Ziel für neue Projekte.

Das ist kein Vorwurf an das LimeSurvey-Team. Es ist vielmehr ein sehr typischer Effekt langfristiger Modernisierung unter Rückwärtskompatibilität.

Infrastruktur modernisiert sich schneller als Domänenlogik

Das eigentlich Interessante an dieser Konfiguration ist nicht das fehlende require. Es ist was sie über die Modernisierungsgeschwindigkeit verschiedener Schichten aussagt.

In langlebigen Systemen modernisiert sich nie alles gleichzeitig. Was typischerweise schnell vorangeht:

• Build-Prozesse und CI/CD-Pipelines
• Composer-Konfiguration und Dependencies
• Docker-Umgebungen
• Frontend-Tooling
• unterstützte Plattformen

Was deutlich langsamer folgt:

• Domänenlogik und Kernarchitektur
• Datenmodell
• Zustandsmanagement
• strukturelle Entkopplung

Das Ergebnis ist ein System das nach aussen modern wirkt – aktuelle Dependencies, aktuelle PHP-Version in der Konfiguration – während der Kern noch deutlich ältere Muster trägt. Bei LimeSurvey sieht man das an createFieldMap(), an LimeMailer, an den globalen Helper-Funktionen.

Infrastruktur kann oft relativ isoliert modernisiert werden.

Domänenlogik dagegen trägt die Last der Rückwärtskompatibilität.

Das ist kein Versagen – es ist die ehrliche Realität von Software die unter realen Bedingungen über viele Jahre produktiv genutzt wurde.

PHP 8.x verändert was möglich ist

Die Diskussion über neue PHP-Versionen dreht sich meistens um Syntax und Performance. Der tiefere Unterschied liegt woanders: neue Sprachfeatures verändern welche Architekturstile praktisch umsetzbar werden.

PHP 8.x hat hier viel verändert. Constructor Property Promotion, readonly Properties, Enums, Union Types, Match Expressions – das ist nicht nur weniger Boilerplate. Es sind Werkzeuge die immutable Objekte, explizite Domänenmodelle und klarere Zustandsübergänge erst praktikabel machen.

Ältere PHP-Versionen fördern andere Strukturen – nicht weil die Entwickler es falsch gemacht haben, sondern weil die Sprache keine besseren Werkzeuge bereitstellte. Mutable ActiveRecord-Objekte, stringbasierte Statuswerte, globale Zustände: das sind Antworten auf eine Sprache die diese Probleme anders lösen musste.

platform.php = 8.1.29 bedeutet also auch: die Infrastruktur bewegt sich bereits in Richtung moderner PHP-Architektur. Die Frage ist, wie schnell der Code darunter nachzieht.

Der develop-major-Branch als Spiegel

Genau das macht den develop-major-Branch architektonisch interessant. Er zeigt wie Modernisierung in langlebigen Open-Source-Systemen tatsächlich abläuft: nicht als vollständiger Rewrite, sondern als schrittweise Verschiebung technologischer Grenzen – von aussen nach innen, von Infrastruktur zu Domäne.

Das SGQA-Schema – 112233X12X42 – ist der vielleicht deutlichste Beleg dafür. Eine Architekturentscheidung aus dem Jahr 2006 die 15 Jahre lang im Bugtracker stand und jetzt in LimeSurvey 7 endlich angegangen wird. Nicht weil niemand es früher wollte – sondern weil es eine Breaking Change ist, die man sich erst leisten kann wenn alles andere stabil genug ist.

Asymmetrische Modernisierung ist kein Zeichen gescheiterter Entwicklung. Sie ist fast schon unvermeidlich – und wer das versteht, versteht auch warum professionelle Softwareentwicklung selten damit beginnt, komplett neu anzufangen.

Wer mehr über die Entwicklungsgeschichte von LimeSurvey lesen möchte: 20 Jahre LimeSurvey – eine Entwicklungsgeschichte in drei Phasen