Release Plan
Unter einem Release ist hier die Veröffentlichung einer neuen Version des Testcenters zu verstehen. Beim Einsatz des Testcenters z. B. in aufwändigen Server-Umgebungen ist es wichtig zu wissen, zu welchen Zeitpunkten Releases mit welchen Eigenschaften erfolgen. Erst auf dieser Grundlage kann man ergänzende Maßnahmen wie Sicherheits-/Penetrationstests und Lasttests planen.
Die Ausführungen auf dieser Seite beziehen sich auf das IQB-Testcenter. Durch die Modularisierung nach dem Verona-Prinzip kann es Programmierungen geben (Player), die ebenfalls für die Testdurchführung erforderlich sind. Deren Release-Planung wird hier nicht thematisiert.
Versionierung
Für das Testcenter wird eine Versionierung nach dem Prinzip der Semantischen Versionierung verwendet. Danach besteht die Versionsangabe aus drei Zahlen und einem optionalen Suffix. Beispiele: 12.0.4
, 15.4.0-beta
.
- Die erste Zahl wird Hauptversion oder MAJOR genannt. Wenn diese Zahl hochgezählt wird, gibt es Änderungen an Schnittstellen und Datenformaten, die grundsätzlich die Installation, die Anbindung an andere Softwarelösungen sowie die Nutzung von Datenobjekten betreffen. Es könnte sein, dass die neue Hauptversion die alten Daten nicht mehr verarbeiten kann. Hinweise hierzu sowie ggf. Migrationsstrategien sind dann im Rahmen der Veröffentlichung dokumentiert.
- Das Hochzählen der zweiten Zahl (sog. MINOR) nennt man Funktions-Update. Es handelt sich um eine Erweiterung der Funktionen ohne Beeinträchtigung der Kompatibilität zu früheren Versionen.
- Die letzte Zahl nennt man PATCH, was soviel bedeutet wie Beheben eines Fehlers. Es gibt nur Änderungen, die dem mit MAJOR.MINOR erwartete Funktionieren des Systems sicherstellen. Dazu zählt auch der Austausch einer Komponente, die zwar nicht Teil der Programmierung ist, aber Teil der Auslieferung ist.
- Wenn die Versionsangabe mit einem Suffix endet, handelt es sich nicht um eine reguläre Freigabe. Die Veröffentlichung ist dann eine Vorabversion, die Fehler bzw. nicht erwartetes Verhalten enthalten kann. Die Veröffentlichung wird vorgenommen, um in vielen technischen Umgebungen das System installieren und ausprobieren zu können. Am IQB werden folgende Suffixe verwendet:
alpha
: Der Kreis der Nutzerinnen und Nutzer soll die implementierten Funktionen prüfen. Manchmal zeigt sich dabei, dass die Anforderungen unklar waren oder es tauchen neue Ideen oder Sichtweisen auf. Nach der alpha gibt es also ggf. noch grundsätzliche Änderungen an den Funktionen.beta
: Die Diskussion über die Funktionen ist abgeschlossen, das IQB hat aber die Software-Tests noch nicht abgeschlossen. Insbesondere erfolgen hier manuelle Tests. Prüfungen einer beta-Version können Fehler in der Implementierung aufzeigen.rc
: Bei einem Release Candidate sind die Prüfungen am IQB abgeschlossen. Es folgen nun Prüfungen durch Partner bzw. in ungewöhnlichen Umgebungen. Hier sind auch Last- und Sicherheitstests anzusiedeln.
Grundsätze
Release-Pfade
- Der Ort der Veröffentlichung ist GitHub.com.
- Es ist die Markierung
Latest
gesetzt für die letzte sog. stabile Version. Diese sollten alle installieren, die neu das IQB-Testcenter auf eigener Infrastruktur nutzen möchten. Auf diese Version beziehen sich Dokumentation und Handreichungen. - Jede Veröffentlichung einer neuen stabilen Version erhält einen ausführlichen Text, der die Änderungen gegenüber der Vorversion beschreibt.
- Alle Versionen mit einem Suffix gelten als Vorabversion und erhalten die Markierung
Pre-release
. - Sollte in besonderen Fällen Patches für eine frühere, nicht als
Latest
markierte Version veröffentlicht werden, ist diese Version weder alsPre-release
noch alsLatest
markiert. - Bei der Veröffentlichung einer Vorabversion wird nur kurz beschrieben, welchen Zweck sie hat.
- Ältere Hauptversionen werden nicht weiterentwickelt und erhalten keine Patches. In besonderen Fällen und in Abstimmung mit dem IQB kann davon abgewichen werden.
- Stabile Versionen können Funktionen enthalten, die noch in der Entwicklung sind. Diese sind als
Preview
in der Release-Dokumentation markiert und sind nach der Installation bzw. dem Update deaktiviert. Über ein dokumentiertes Verfahren werden sie aktiviert bzw. zugänglich. Diesen Weg geht das Entwicklerteam, wenn es frühzeitig Rückmeldungen aus dem Nutzerkreis für neue Funktionen erhalten möchte oder eine bestimmte Änderung, für die eine Hauptversion erforderlich wäre, früher verfügbar machen möchte. - Funktionen, die mit der nächsten Hauptversion entfallen oder grundlegend überarbeitet werden, können in einem stabilen Release als
deprecated
markiert werden. Diese Markierung erfolgt im Text des Releases.
Termine und Planung
Im Jahr 2025 wird es noch eine Reihe von Releases geben, die nicht streng terminlich getaktet sind. Es sollen Verbesserungen – auch größere Änderungen – möglichst schnell verfügbar gemacht werden. Ab 2026 sollen zur besseren Planbarkeit die Releases zu bestimmten Zeitpunkten erfolgen:
- Einmal im Jahr im März wird eine Hauptversion veröffentlicht.
- Hauptversionen werden mit den beabsichtigten Funktionen mindestens ein halbes Jahr vorab angekündigt (s. u.).
- Mit der neuen Hauptversion wird die jährliche VERA-Pilotierung durchgeführt (entspr. Umstellungsplan beginnend 2026 mit Primarstufe).
Funktions-Updates werden nach Bedarf und nach verfügbaren Ressourcen veröffentlicht. Sie werden mindestens 1 Monat vorab angekündigt (s. u.).
Aktuelle Termine
Nächste Hauptversion 17
- Termin: vorauss. 1.7.2025
- Geplante Änderungen:
- Performance-Verbesserungen im Backend
- Refactoring der Auslieferung der Testinhalte (Files-Container)
- Anmerkung: Grundlage dafür sind diverse Lasttests, die das IQB ausführlich dokumentieren wird.
Nächste Hauptversion 18
- Termin: vorauss. 1.10.2025
- Geplante Änderungen:
- Überarbeitung im Bereich UI/UX. Der Start-/Anmeldvorgang wird neu gestaltet. Die Flexibilität des Designs wird mit Einführung von Angular Material Theming verbessert.
- Anmerkung: Die Anpassungen führen zur besseren Passung für die 4 Zielgruppen 1./2. Klasse, 3./4. Klasse, 8./9. Klasse sowie Erwachsene.