3.0 KiB
V2.0.1 Account Manager und Startup
Ziel
Multi-Hoster-Upload wird als sichtbare Produktversion 2.0.1 ausgeliefert. Das Hinzufügen und Bearbeiten eines Accounts validiert und speichert in einem Klick. Ein fehlgeschlagener, abgebrochener oder veralteter Check verändert weder die persistierte noch die im Renderer gehaltene Account-Konfiguration. Der intermittierende weiße Startzustand wird durch einen deterministischen Software-Renderer und ein erst nach erfolgreichem Laden sichtbares Hauptfenster verhindert.
Account-Flow
Der Button lautet im Anlegefall Prüfen und anlegen, im Bearbeitungsfall Prüfen und speichern. Der bestehende Credential-Check bleibt die einzige fachliche Validierung. ok und warn führen unmittelbar zum Save, error, skipped, IPC-Fehler und otp_required nicht. OTP zeigt das Eingabefeld; der nächste Klick validiert und speichert in einem Lauf.
Ein einziger Busy-Zustand umfasst Check und Save. Vor dem Save werden Modal-Session, Hoster, Account-ID und Credential-Snapshot erneut abgeglichen. Hoster- oder Credential-Änderung, Schließen oder erneutes Öffnen invalidieren die laufende Operation. Der Kandidat wird auf einer Kopie der Hoster-Konfiguration aufgebaut. Erst nach erfolgreichem saveConfig ersetzt er den Renderer-State. Bei Save-Fehler bleibt das Modal offen und der bisherige State unverändert.
Startup
Die App benötigt keine GPU-beschleunigten Canvas-, WebGL- oder Video-Oberflächen. Hardwarebeschleunigung wird deshalb bei jedem Start vor app.whenReady() deaktiviert, unabhängig von SESSIONNAME und einem späteren GPU-Crash. Das Hauptfenster startet mit show: false, wird auf ready-to-show eingeblendet und wertet das Promise von loadFile aus. Load- und Renderer-Fehler bleiben sichtbar diagnostizierbar.
Versions- und Update-Brücke
package.json, UI, Installer-Metadaten und öffentliche GitHub-Version lauten 2.0.1 beziehungsweise v2.0.1. Der ausgelieferte 3.3.108-Client vergleicht den privaten Gitea-Tag numerisch und würde einen Tag v2.0.1 ablehnen. Außerdem existiert dort bereits ein historischer Tag v2.0.1.
Der private Updater-Transport verwendet deshalb für diese Veröffentlichung den neuen internen Tag v3.3.109, während Release-Titel und Build v2.0.1 anzeigen. Der neue Updater liest die Produktversion aus dem Release-Titel und fällt nur bei fehlender Produktversion auf den Tag zurück. Dadurch sieht 3.3.108 den höheren Transport-Tag, während 2.0.1 denselben Release anhand des Titels als bereits installiert erkennt. Künftige 2.x-Releases verwenden fortlaufende interne Transport-Tags oberhalb 3.3.108 und sichtbare 2.x-Titel.
Verifikation
Regressionsfälle prüfen den real verwendeten Account-Submit-Core, die Startup-Konfiguration und die Produkt-/Transport-Versionsauflösung. Danach folgen vollständige Unit-Tests, UI-Smoke, wiederholte reale Starts, Windows-Build, entpackte Artefaktprüfung, Secret-Scans, isolierter Installer-/Updater-Test und erst anschließend die kuratierten privaten und öffentlichen Releases mit erneutem Download und Hashvergleich.