Dein Datenformat bleibt lesbar. Für immer.

Das Monica-Chandler-Problem

Apps, die persönliche Daten verwalten, haben ein strukturelles Vertrauensproblem: Nutzer:innen wissen nie genau, ob ein Update ihre Daten still umbricht. Monica, ein beliebter Open-Source-Personal-CRM, hat über die Jahre das Datenbankschema mehrfach geändert — und wer nicht regelmäßig exportiert oder auf Migrations-Fehler geachtet hat, stand manchmal mit inkonsistenten Daten da.

Wir nennen das das "Monica-Chandler-Problem": Die Angst, dass ein Update Julias Knie-OP-Notiz, Mikes Spitznamen oder drei Jahre Interaktionshistorie still überschreibt, weil die Migration einen Edge-Case nicht bedacht hat.

Unser Versprechen: Das passiert bei Endearist nicht. Hier steht konkret, wie wir das durchsetzen.

Wie Migrations-Disziplin technisch aussieht

Schema-Dumps vor jedem Versions-Bump

Bevor wir die Datenbank-Versionsnummer erhöhen, wird ein vollständiger Schema-Dump in das Repository committed. Das ist eine harte technische Regel — kein Versions-Bump ohne committed Schema-Snapshot. Wenn du in zehn Jahren schaust, welches Schema v1.4.2 hatte, findest du es im Git-Log.

Migrations nur vorwärts, reversibel über JSON

Alle Datenbank-Migrationen laufen in eine Richtung: von alt nach neu. Wir schreiben keine Migrationen, die Daten irreversibel löschen oder transformieren, ohne einen Pre-Migration-Snapshot zu erstellen. Vor jeder Migration wird ein vollständiger JSON-Export der betroffenen Daten gespeichert — als Sicherheitsnetz, falls die Migration fehlschlägt oder einen Fehler enthält.

Das bedeutet konkret: Wenn eine Migration schlägt fehl, wird der Pre-Migration-Snapshot automatisch restored. Du bekommst eine Fehlermeldung, aber keinen Datenverlust. Das ist nicht optional — es ist Teil der Migrations-Pipeline.

Schema-Version in jeder Backup-Datei

Jedes automatische Backup enthält die Schema-Version, unter der es erstellt wurde. Das bedeutet: Wenn du ein Backup von v1.2.0 mit Endearist v2.5.0 öffnest, weiß die App exakt, welche Migrationen sie anwenden muss — und sie tut es in Reihe, verifiziert, mit Pre-Step-Snapshots.

Was das in der Praxis bedeutet

Vorwärtskompatibilität über Releases hinweg

Jeder Release-Kandidat muss alle Migrations-Schritte von v1 bis zur aktuellen Version erfolgreich durchlaufen. Das wird als Teil der Continuous-Integration-Pipeline geprüft — kein Release geht raus, wenn der Migrations-Roundtrip fehlschlägt. "Alle Migrationen von v1 bis heute müssen round-trippen" ist eine der Pre-Merge-Bedingungen in unserer Engineering-Dokumentation.

Dein Datenformat ist kein proprietäres Geheimnis

Das SQLite-Schema ist dokumentiert. Der Markdown-Export-Entwurf ist öffentlich. Selbst wenn Endearist morgen aufhören würde zu existieren, könntest du mit einem Standard-SQLite-Tool deine Daten öffnen und lesen — ohne proprietäre Software, ohne uns.

Was wir versprechen und was nicht

Wir versprechen: Jede neue Version von Endearist kann Daten jeder älteren Version öffnen. Jede Migration ist getestet. Kein Silent-Drop von Datenfeldern ohne explizite Benutzerwarnung.

Wir versprechen nicht: Rückwärtskompatibilität — eine ältere App-Version kann möglicherweise keine Daten öffnen, die mit einer neueren Version erstellt wurden. Das wäre technisch schwer durchzuhalten und gibt dir keinen praktischen Mehrwert, weil du immer auf die neueste Version aktualisieren kannst.