Version 1.0.0 — Freigabe für den Echtbetrieb (#17)
This commit was merged in pull request #17.
This commit is contained in:
@@ -6,6 +6,84 @@ Alle nennenswerten Änderungen an FLORIAN. Format nach
|
||||
|
||||
Die Regeln dazu stehen in [docs/VERSIONIERUNG.md](docs/VERSIONIERUNG.md).
|
||||
|
||||
## [1.0.0] — 2026-09-06
|
||||
|
||||
**Freigabe für den Echtbetrieb.**
|
||||
|
||||
Kein neues Modul. Zwölf Phasen sind fertig, und die Wehr kann ab jetzt echte
|
||||
Daten hineingeben, ohne befürchten zu müssen, sie beim nächsten Update zu
|
||||
verlieren.
|
||||
|
||||
Was 1.0.0 bedeutet: der Funktionsumfang ist vollständig, die Datenbank ist
|
||||
stabil, Migrationen sind aufwärtskompatibel, und ab hier gilt semantische
|
||||
Versionierung — ein Update bricht nichts, ohne dass es in der Hauptnummer
|
||||
steht.
|
||||
|
||||
Was es nicht bedeutet: dass keine Fehler mehr da sind.
|
||||
|
||||
### Hinzugefügt
|
||||
|
||||
- **`update.sh`** — Aktualisieren auf einem Linux-Server, in einem Befehl. Der
|
||||
Ablauf darf an jeder Stelle abbrechen, ohne eine halb aktualisierte Anlage
|
||||
zu hinterlassen: erst nachsehen, ob es überhaupt etwas Neues gibt, dann
|
||||
**sichern**, dann holen und bauen (schlägt das fehl, läuft die alte Fassung
|
||||
unverändert weiter), dann umschalten, dann nachsehen, ob die Anwendung
|
||||
antwortet. Tut sie es nicht, stehen die letzten Protokollzeilen da und die
|
||||
Befehle, mit denen der vorherige Stand zurückkommt.
|
||||
|
||||
Vorher prüft es Docker, git, die `.env` und dass keine unverbuchten
|
||||
Änderungen im Verzeichnis liegen. `--pruefen` sieht nur nach,
|
||||
`--ohne-sicherung` gibt es für Testinstallationen.
|
||||
|
||||
- **`docs/KURZANLEITUNG.md`** — der Einstieg, nach Rollen sortiert und auf ein
|
||||
paar Seiten. Die vollständige Anleitung hat 63 Kapitel; die liest niemand,
|
||||
bevor er das erste Gerät prüfen will. Diese hier ist aufgabenorientiert
|
||||
(„ein Gerät prüfen", „einen Kontoauszug einlesen") statt nach Modulen
|
||||
geordnet, und sie sagt bei jedem heiklen Punkt dazu, warum es so ist — warum
|
||||
ein abgeschlossenes Prüfprotokoll nicht änderbar ist, warum gegengebucht und
|
||||
nicht korrigiert wird, warum der Atemschutzhinweis stehen bleibt.
|
||||
|
||||
### Geändert
|
||||
|
||||
- Version auf **1.0.0**. Ab hier gilt semantische Versionierung nach
|
||||
[docs/VERSIONIERUNG.md](docs/VERSIONIERUNG.md).
|
||||
- Die Roadmap hält den Stand **jeder** Freigabevoraussetzung fest, auch der
|
||||
offenen. Zwei sind organisatorisch und stehen aus: die Abnahme des
|
||||
Löschkonzepts durch die Wehr und die Schulung. An der Software hängt nichts
|
||||
davon ab; sie stehen dort, damit später nachlesbar ist, was zum Zeitpunkt
|
||||
der Freigabe erledigt war und was nicht.
|
||||
|
||||
### Behoben
|
||||
|
||||
- **Die Testläufe flackerten seit Phase 8 — jetzt ist die Ursache weg.** Zwei
|
||||
Datenbanktests schalteten beim Aufräumen ihre Trigger mit
|
||||
`ALTER TABLE ... DISABLE TRIGGER` ab. Das ist eine Schemaänderung: sie gilt
|
||||
für die ganze Datenbank und für alle. Vitest fährt die Testdateien parallel
|
||||
— während die eine Datei abräumte, prüfte die andere gerade, dass genau
|
||||
dieser Trigger greift, und sah keinen.
|
||||
|
||||
Das erklärt rückwirkend eine ganze Reihe von Fehlschlägen, die als
|
||||
„Flackern" abgetan wurden und keines waren. Statt der Schemaänderung wird
|
||||
jetzt `SET LOCAL session_replication_role = 'replica'` benutzt: dieselbe
|
||||
Wirkung, aber nur in der eigenen Transaktion. Fünf Läufe hintereinander
|
||||
sauber.
|
||||
|
||||
- **Ein Datenbanktest räumte nur am Ende auf.** Brach ein Lauf ab, scheiterte
|
||||
der nächste an einer Eindeutigkeit, die mit dem Geprüften nichts zu tun
|
||||
hatte. Er räumt jetzt auch am Anfang auf.
|
||||
|
||||
### Zum Stand der Freigabevoraussetzungen
|
||||
|
||||
| Voraussetzung | Stand |
|
||||
|---|---|
|
||||
| Datenübernahme | **entfällt** — die Wehr pflegt von Hand ein |
|
||||
| Sicherungskonzept, einmal wiederhergestellt | **erledigt** (Phase 11) |
|
||||
| Löschkonzept nach DSGVO | **technisch vollständig** (Phase 11), Abnahme steht aus |
|
||||
| Schulung | **steht aus**, Grundlage ist die Kurzanleitung |
|
||||
| Atemschutzhinweis | **bewusst stehen gelassen** — FLORIAN bleibt ergänzend |
|
||||
|
||||
---
|
||||
|
||||
## [0.12.0] — 2026-09-05
|
||||
|
||||
Phase 11: Freigabereife. Die drei Software-Voraussetzungen für 1.0.0 —
|
||||
|
||||
Reference in New Issue
Block a user