Die Release Notes von LimeSurvey sind öffentlich zugänglich. Sie beginnen mit Changes from 0.98 to 0.99 und enden – Stand heute – bei 7.0.0-RC1 vom 30. April 2026. Über 11.000 Zeilen, die niemand vollständig liest – und die zusammen eine Geschichte erzählen, die so komprimiert nirgendwo steht.
Diese Geschichte hat drei Phasen. Sie erklärt, warum LimeSurvey so ist wie es ist – und was LimeSurvey 7 jetzt konkret bedeutet.
Phase 1: Der Aufbau (0.99 bis ~1.90, 2006–2012)
Die frühe Phase ist bemerkenswert dicht. Innerhalb weniger Jahre entstand das konzeptuelle Fundament, auf dem LimeSurvey bis heute steht.
Version 1.50 (2007) brachte die Mehrsprachigkeit, das neue Admin-Interface, detaillierte Benutzerrechte und die ersten Exportformate. Version 1.80 (2009) führte den Slider als neuen Fragetyp ein, das Quota-System, Token-Attribute und den SPSS-Export. Version 1.90 (2012) brachte den Expression Manager – eine eingebettete Skriptsprache für Verzweigungslogik und Berechnungen, die bis heute der leistungsfähigste Teil des Systems ist.
Die Sprache dieser Release Notes ist die Sprache von Menschen die Dinge bauen. Jeder Eintrag nennt einen Autor namentlich. Die Commits kommen von einer überschaubaren Gruppe: c_schmitz, lemeur, jcleeland, el-matador-69. Viele Einträge tragen den Kommentar „patch kindly provided by" – ein Projekt, das damals noch echten Community-Charakter hatte.
Ein Detail am Rande, das erst im Rückblick auffällt: Die Release Notes wurden über 20 Jahre kontinuierlich gepflegt. Jede Version, jeder Fix, jeder Autor – dokumentiert. Das ist keine Selbstverständlichkeit. Viele Open-Source-Projekte dieser Größe haben fragmentierte Changelogs oder gar keine. Diese Disziplin ist ein stilles Qualitätsmerkmal des Projekts.
Die Architekturentscheidungen dieser Phase gelten bis heute:
- Das SGQA-Schema für Antwortspalten (
112233X12X42) - Das Token-System mit Session-Key
- Der Expression Manager als eigene Mini-Sprache
- Das Plugin-System mit Event-Dispatching
- Die survey-spezifischen Antworttabellen (
survey_<sid>)
Keine dieser Entscheidungen wurde seither grundlegend revidiert. Sie waren richtig für die damaligen Anforderungen, die damaligen Werkzeuge und das damalige PHP – das war PHP 5, vor Namespaces, vor Composer, vor Typdeklarationen.
Phase 2: Die Konsolidierung (2.x bis 4.x, 2012–2021)
Mit Version 2.0 (2012) kam das erste große Redesign: ein neues Admin-Interface auf Bootstrap-Basis, die Migration auf das Yii-Framework, Fancy URLs, eine überarbeitete Template-Engine. Das war die letzte Phase, in der LimeSurvey architektonisch voranging.
Version 3.0 (2017) brachte Twig als Template-Engine – allerdings nur für Survey-Themes, nicht für das Admin-Interface. Ein signifikanter Fortschritt, aber ein halber. Das Plugin-System wurde ausgebaut, das Remote-Control-Interface erweitert, Verschlüsselung für sensible Felder eingeführt.
Was in dieser Phase parallel sichtbar wird: Die Bugfix-Listen werden länger. Die Feature-Ankündigungen kürzer. Und die bekannten Kategorien tauchen auf:
- SQL-Injection-Fixes
- XSS-Vulnerabilities
- Copy-Survey-Bugs
- Token-Import-Probleme
- MSSQL-Inkompatibilitäten
Diese Kategorien sind kein Zeichen schlechter Entwickler. Sie sind das Signal einer Codebasis, die unter wachsender Last steht. Mehr Fragetypen, mehr Datenbanktreiber, mehr Exportformate – und ein Kern, der nicht für diese Breite gebaut wurde.
Die Yii-Geschichte illustriert das Dilemma präzise. LimeSurvey migrierte auf Yii 1. Yii 2 erschien 2014 – ein Rewrite, kein Upgrade. Kein funktionierender Migrationspfad. LimeSurvey blieb auf Yii 1, das seinerseits Teile von Zend Framework 1 verwendet – unter anderem für den XML-RPC-Handler der RemoteControl-API. Zend Framework 1 ist seit Jahren offiziell eingestellt. Die Community pflegt es heute unter dem Namen shardj/zf1-future weiter – ein Paket, das auf Packagist inzwischen als „Abandoned" markiert ist. LimeSurvey hängt also nicht nur an einem ungepflegten Framework, sondern an einer Komponente eines ungepflegten Frameworks, die von Freiwilligen am Leben gehalten wird. Das ist kein Versagen – das ist die direkte Konsequenz aus dem, was wir im Rewrite-Reflex-Artikel beschrieben haben.
Phase 3: Die Pflege (5.x bis 6.x, 2021–heute)
Die aktuelle Phase lässt sich in drei Worten zusammenfassen: Stabilisierung, Security, Accessibility.
Feature-Releases gibt es noch – sie sind aber selten und klein. Ein neuer Kopierprozess für Umfragen. Eine wartbare Maintenance-Seite. Eine verbesserte Benutzerverwaltung. Keine architektonischen Einschnitte.
Was die Release Notes dieser Phase dominiert: Security-Fixes. XSS, SQL-Injection, CSRF, Path Traversal, Privilege Escalation – in praktisch jedem Release, regelmäßig gemeldet von externen Sicherheitsforschern. Das ist kein Vorwurf. Es zeigt aber, dass die strukturellen Ursachen – fehlende Input-Validierung als Architekturprinzip, globale Abhängigkeiten, schwer testbarer Code – nicht behoben wurden. Man bekämpft Symptome.
Ab Ende 2025 taucht das „Anblik Audit Team" auf. Release für Release liefern sie Accessibility-Fixes: aria-labels, Rollenattribute, Fokusmanagement, Screen-Reader-Kompatibilität. Dutzende Einträge in wenigen Wochen. Das war kein organisches Wachstum – das war ein externer Audit, der einen systematischen Rückstand aufgearbeitet hat. Positiv ist: er wurde in Auftrag gegeben. Das Signal dahinter ist trotzdem klar.
Und dann ist da noch das eine Release, das in seiner Kürze fast komisch ist:
Changes from 6.16.6 (build 260204) to 6.16.7 (build 260205) February 4, 2026
-Fixed issue: release notes file is empty (Patrick Teichmann)
Ein Release ausschließlich um zu fixen, dass die Release Notes leer waren. Kein Kommentar nötig.
LimeSurvey 7: Was der RC1 zeigt
Am 30. April 2026 erschien 7.0.0-RC1. Der Eintrag in den Release Notes ist kurz:
Changes from 6.17.1 (build 260427) to 7.0.0-RC1 (build 260430) April 30, 2026
IMPORTANT
-Do not use this version for production
New feature: New easy-to-use survey editor - check it out!
New feature: Response table name & schema changes
New feature #20387: Keep certain subquestions/answer options at original positions on randomization
Drei Einträge für einen Release Candidate. Hinter diesen drei Zeilen steckt mehr als die Kürze vermuten lässt – das Manual liefert die Details.
Das SGQA-Ende ist vollständig dokumentiert. Die Umbenennung ist konkret:
| Alt | Neu |
|---|---|
survey_<sid> |
responses_<sid> |
survey_<sid>_timings |
timings_<sid> |
old_survey_<sid>_<timestamp> |
old_responses_<sid>_<timestamp> |
Feldnamen folgen künftig einem lesbaren Schema: Q<questionId> für die Rootfrage, Q<questionId>_S<subquestionId> für Subfragen, Q<questionId>_C<suffix> für Kommentarfelder. Das ersetzt das Legacy-sidXgidXqid-Schema – also 112233X12X42 – vollständig. Den Hintergrund dazu haben wir im Datenbankmodell-Artikel beschrieben.
Das Core-Team hat an den Übergang gedacht: Es gibt eine Migrationsfunktion getFieldName(), die alte Feldnamen auf neue abbildet, und eine klare Anleitung zum Testen in einer separaten Umgebung. Plugins, direkte Datenbankzugriffe, Custom JavaScript und bestehende Integrationen müssen dennoch geprüft und angepasst werden. Das ist eine echte Breaking Change – aber eine mit Migrationspfad.
Der neue Editor ist React-basiert – und bringt eine Infrastrukturvoraussetzung mit, die in den Release Notes nicht erwähnt wird. Der Editor erfordert das path-URL-Format. Wer von einer älteren Version upgradet und noch das Standard-get-Format verwendet, muss in der config.php manuell umstellen:
'urlManager' => array(
'urlFormat' => 'path', // war: 'get'
...
),
Das setzt serverseitig URL-Rewriting voraus – Apache mod_rewrite, nginx try_files oder das IIS-Äquivalent. Auf Shared Hosting ohne Zugriff auf die Serverkonfiguration kann das eine echte Hürde sein. Dazu kommt: Das Umstellen des URL-Formats bricht bereits versendete Einladungslinks. Wer aktive Umfragen laufen hat, muss entweder neue Links verschicken oder serverseitige Weiterleitungen einrichten.
Was der RC1 insgesamt zeigt: LimeSurvey 7 ist durchdacht – mehr als viele Breaking Changes in der Projektgeschichte. Beta1 erschien im Januar 2026, beta2 im April, RC1 Ende April. Die strukturellen Änderungen sind dokumentiert, die Migrationspfade beschrieben. Ob die Community-Praxis das bestätigt, werden die Erfahrungsberichte nach dem stabilen Release zeigen.
Was 11.000 Zeilen sagen
Die Release Notes von LimeSurvey erzählen eine Geschichte, die für jede gewachsene Software gilt.
Eine frühe Phase, in der ein kleines Team unter Zeitdruck fundierte Entscheidungen trifft – Entscheidungen, die zum damaligen Kontext passen und sich über Jahre bewähren. Eine mittlere Phase, in der das System wächst und die Entscheidungen von damals zunehmend zur Last werden. Eine reife Phase, in der Stabilisierung wichtiger wird als Neues – und in der externe Audits sichtbar machen, was intern liegen geblieben ist.
Das ist kein Versagen. Das ist Softwareentwicklung.
Was LimeSurvey von anderen Systemen unterscheidet: Es läuft noch. Nach 20 Jahren, 11.000 Zeilen Release Notes und einem Fundament aus PHP 5. Die Release Notes sind der Beweis – für Lebensdauer, für akkumuliertes Wissen und für die Grenzen dessen, was ohne strukturelle Änderungen möglich ist.
LimeSurvey 7 ist der erste ernsthafte Versuch, diese Grenzen zu verschieben. Der RC1 ist da. Ob er hält was er verspricht, werden die nächsten Release Notes zeigen.