# Release-Workflow

Wenn der Benutzer „Bau den Installer und lade es auf Gitea hoch“ oder einen
sinngleichen Auftrag gibt, ist immer der vollständige Release-Workflow
autorisiert:

1. Änderungen seit dem letzten Release prüfen und einen deutschen Abschnitt
   für die nächste Patch-Version in `CHANGELOG.md` ergänzen.
2. `build_installer.ps1` ohne `-NoVersionBump`, `-SkipGit` oder `-SkipPublish`
   starten. Das Skript erhöht die Patch-Version, führt Tests und Ruff aus,
   baut die eigenständige PyInstaller-EXE, prüft ihren Start, erstellt den
   Inno-Setup-Installer, committed und pusht den Quellstand und veröffentlicht
   den Gitea-Release.
3. `publish_gitea_release.ps1` nicht zusätzlich starten; das Build-Skript ruft
   es selbst auf.
4. Abschließend den veröffentlichten Release und seine drei Assets über die
   öffentliche Gitea-API prüfen.

Bei Fehlern keine Prüfung überspringen und keinen fehlerhaften Build
veröffentlichen. Python, PyQt6, watchdog und alle weiteren
Laufzeitabhängigkeiten müssen in der EXE enthalten sein; auf dem Zielsystem
darf keine Python-Installation vorausgesetzt werden.

# Interner Updater

Der Client lädt ausschließlich `SyncVitoSetup-<Version>.exe` und die zugehörige
SHA-256-Datei aus dem neuesten stabilen öffentlichen Gitea-Release. Nach der
Verifikation startet ein abgekoppelter Wächter. Dieser wartet auf den
vollständigen Abschluss des PyInstaller-Eltern- und Kindprozesses und startet
erst danach Inno Setup. Ein direkter Austausch der laufenden EXE ist nicht
zulässig. Bootstrap- und Inno-Setup-Protokolle bleiben für die Diagnose im
lokalen Update-Verzeichnis erhalten.