Roadmap

Release-Roadmap

Wo wir gerade stehen, was als Nächstes kommt. Die Übersicht zeigt unsere Release-Termine im Zwei-Monats-Takt, mit aktuellem Stand der Entwicklung.

Dez. 25 Jan. 26 Feb. 26 März 26 Apr. 26 Mai 26 Juni 26 Juli 26 Aug. 26 Sept. 26 Okt. 26 Nov. 26 Dez. 26 Jan. 27
4.2.13.0 Lord Monkey Fist
4.2.14.0 Bridge Monkey
4.2.15.0 J. Fred Muggs
4.2.16.0 Koko
4.2.17.0 Caesar
4.2.18.0 Jiggs
4.2.19.0 Nim Chimpsky
veröffentlicht
veröffentlicht
in Arbeit
geplant
geplant
geplant
Heute · 04.06.2026

Wir deployen mit Bedacht und reagieren schnell, wenn etwas auffällt.

Ein Release-Termin ist nicht der Tag, an dem alle Häuser umgestellt werden. Hier steht, wie wir Versionen tatsächlich ausrollen und was passiert, wenn doch etwas hakt.

Rollout in Wellen

Nach dem Release-Termin geht eine neue Version nicht auf einen Schlag in alle Installationen. Wir deployen Schritt für Schritt und beobachten dabei jede Umgebung gezielt. go~mus ist keine einfache zentrale SaaS-Anwendung, sondern eine Enterprise-Plattform mit vielfältigen, verzweigten Szenarien pro Museum, Schnittstelle und Workflow.

Testing und Automatisierung

Vor jedem Release laufen automatische Test-Szenarien gegen die zentralen Geschäftsabläufe: Online-Verkauf, Buchungsflows, Kasse, Reservierungen, Wallet-Tickets, REST API. Dazu Code-Reviews für jeden Pull Request und manuelle Tests auf der Staging-Umgebung. Trotzdem: 100 % Abdeckung gibt es bei Software dieser Größenordnung nicht.

Wenn doch etwas schiefgeht

Wo Software geschrieben wird, entstehen Fehler. Wir geben das offen zu. Wenn nach einem Release etwas auffällt, reagieren wir schnell: priorisierte Bug-Fixes, Hotfix-Deployments innerhalb von Stunden statt Tagen, direkte Kommunikation an die betroffenen Häuser. Ein Release ist kein Punkt im Kalender, sondern ein Prozess, der nach dem Datum weitergeht.