Release-Prozess

Diese Seite dokumentiert den normalen Mindwtr-Release-Ablauf auf praktischer Ebene. Sie richtet sich an Maintainer, die im Repository arbeiten.

---

Quelldateien

Release-Automatisierung und Versionsmetadaten konzentrieren sich auf:

• scripts/bump-version.sh
• scripts/update-versions.js
• docs/release-notes/
• docs/release-notes/google-play/
• metadata/
• metadata/metadata.json
• apps/desktop/src-tauri/linux/Mindwtr.metainfo.xml
• https://github.com/dongdongbh/mindwtr-web/tree/main/docs für Änderungen an der öffentlichen Dokumentation
• wiki/ wurde eingestellt — es enthält nur eine Zielseite, die auf die Dokumentationswebsite verweist; fügen Sie niemals Inhaltsseiten hinzu
• .github/workflows/
• .github/workflows/release-rc.yml für die Release-Candidate-Automatisierung

---

RC-Zug für zweiwöchentliche Releases

Verwenden Sie für normale zweiwöchentliche Minor-Releases einen Release-Candidate-Zug. Dies ist kein allgemeines Beta-Programm. Ein RC ist der Build, der stabil werden soll, sofern Tester keinen Blocker finden.

Verwenden Sie SemVer-Namen für Vorabversionen:

• erster Kandidat: v1.1.0-rc.1
• folgende Blockerkorrektur: v1.1.0-rc.2
• endgültiges stabiles Release: v1.1.0

Ersetzen Sie keine Artefakte für einen RC, der Tester erreicht hat. Beheben Sie einen solchen Fall mit der nächsten RC-Nummer. Wenn ein Lauf fehlschlägt, bevor GitHub das Prerelease veröffentlicht, brechen Sie ihn ab, korrigieren Sie main, löschen Sie den betreffenden RC-Tag, erstellen Sie ihn auf dem korrigierten Commit neu und pushen Sie den Tag erneut.

Führen Sie für einen RC ./scripts/bump-version.sh vX.Y.Z-rc.N aus. Das Skript belässt die Versionsdateien von App und Paketen auf der stabilen Basisversion (X.Y.Z) und schreibt zugleich die vollständige RC-Version für FOSS-Builds ohne Umgebungsvariablen in apps/mobile/release-version.json. Der RC-Workflow prüft beide Werte, bevor die Plattform-Builds beginnen.

Wann der RC-Zug verwendet wird

Verwenden Sie den vollständigen RC-Zug für:

• geplante zweiwöchentliche Minor-Releases
• Releases mit plattformübergreifenden Änderungen
• Releases, die Synchronisierung, Speicherung, Erfassung, Paketierung, Entitlements, Updater-Metadaten oder Store-Metadaten betreffen
• Releases, bei denen sich mehrere Vertriebsartefakte geändert haben

Der Maintainer kann den RC-Zug für triviale Patch-Releases überspringen, etwa eine enge einzeilige Korrektur, eine reine Dokumentationskorrektur oder eine reine Metadatenaktualisierung, die das Verhalten der installierten App nicht beeinflusst. Das Überspringen des Zugs sollte in den Versionshinweisen oder der Release-Checkliste ausdrücklich vermerkt werden.

RC-Kanalmatrix

Veröffentlichen Sie RC-Builds nur in Kanälen, die Tester ohne hohen Wartungsaufwand unterstützen können.

Plattform	RC-Kanal	Stabiles Verhalten
Alle direkten Downloads	GitHub-Prerelease	Das endgültige GitHub-Release wird zur stabilen Downloadquelle.
iOS	TestFlight	Der App Store bleibt der stabile Kanal.
Apple Watch	Watch-fähiges iOS-Archiv in TestFlight	Stabile Releases reichen dasselbe Watch-fähige iOS-Archiv zur App-Store-Prüfung ein und verteilen es über TestFlight.
macOS-App-Store-Build	TestFlight	Der Mac App Store bleibt der stabile Kanal.
Android-Play-Build	Standardmäßig interne Tests und offene Tests (beta) bei Google Play; geschlossene/benutzerdefinierte Tracks, sofern konfiguriert	Production erhält später einen stabilen Upload, und der interne Test-Track wird vom stabilen Workflow aktualisiert.
Linux Flatpak	Flathub-Beta-Branch	Stabile Releases werden sowohl im stabilen als auch im Beta-Branch veröffentlicht, damit Beta-Benutzer nicht zurückbleiben.
Arch Linux	AUR mindwtr-beta-bin	Das stabile Release aktualisiert das dauerhaft bestehende Beta-Paket.
Debian/Fedora Linux	Beta-APT-/RPM-Repositorys	Stabile Pakete verbleiben in getrennten Verzeichnissen der stabilen Repositorys.
Direkter Windows-Download	Installer/portable Version aus dem GitHub-Prerelease	Das endgültige GitHub-Release liefert stabile Downloads.
Windows Microsoft Store	Paket-Flight Mindwtr Beta	Stabile Releases aktualisieren den konfigurierten Flight und die öffentliche Store-Einreichung.

Halten Sie diese Kanäle ausschließlich stabil, sofern kein klarer Bedarf besteht und die Automatisierung bereits vorhanden ist:

• F-Droid
• IzzyOnDroid
• winget
• stabiler Homebrew-Cask
• Chocolatey
• stabiler Scoop-Bucket
• stabile APT-/RPM-Repositorys

Microsoft-Store-Flights verwenden die Repository-Variable MSSTORE_FLIGHT_ID und die vorhandenen Secrets MS_TENANT_ID, MS_CLIENT_ID, MS_CLIENT_SECRET sowie optional MS_STORE_APP_ID. Die App-ID ist standardmäßig 9N0V5B0B6FRX. .github/workflows/msstore-flight-id.yml ermittelt die Flight-ID. Angemeldete Tester erhalten Updates über den normalen Store-Eintrag.

Die RC-Eingabe run_msstore_flight ist standardmäßig true. Für RCs bleibt run_msstore=false; der Windows-Workflow verwendet ausschließlich die Flight-API. Fremde offene Entwürfe werden abgelehnt, einschließlich eines ersten Entwurfs aus Partner Center. Prüfen Sie diesen Flight-Entwurf und veröffentlichen oder verwerfen Sie ihn vor einem erneuten Versuch. Bearbeiten Sie API-erstellte Einreichungen nicht in Partner Center. Die Workflow-Zusammenfassung enthält Einreichungs-ID und Verarbeitungsstatus; Zertifizierung und Installation durch Tester werden getrennt geprüft.

Zur Wiederherstellung eines Store-Flights nach einem veröffentlichten Release akzeptiert .github/workflows/release-msstore-flight.yml einen veröffentlichten stabilen oder RC-Tag. Der Workflow prüft das vorhandene portable Windows-Artefakt anhand des GitHub-SHA256-Digests und verpackt die unveränderte ausführbare Datei. Die Flight-Einreichung verlangt, dass der Vorabversionsstatus des Releases zum Tag passt; öffentliche Release-Artefakte werden nicht ersetzt und die App wird nicht neu gebaut.

Store-Paketversionen verwenden X.Y.(Z*100+N).0 für X.Y.Z-rc.N mit RC-Nummern 1–98 und X.Y.(Z*100+99).0 für stabile Versionen X.Y.Z. Jede Komponente muss in 0–65535 liegen, die erste muss positiv sein. Beispielsweise wird 1.3.0-rc.2 zu 1.3.2.0 und die stabile Version 1.3.0 zu 1.3.99.0. Die vierte Komponente bleibt für den Store null. Stabile Releases aktualisieren auch den konfigurierten Flight, da angemeldete Konten diesem zugeordnet bleiben. Prüfen Sie, dass ein Store-Update Aufgaben und Anhänge erhält.

Für eigenständige Windows-Installer und portable Builds starten Sie Release Windows manuell mit deaktiviertem run_msstore und run_msstore_flight. Die Auswahl eines vorhandenen Tags aktiviert keine Store-Veröffentlichung. Diese Builds akzeptieren eigene Release-Suffixe wie 1.3.0-rc.2a, ohne die Regeln für Store-Paketversionen anzuwenden. Die Veröffentlichung im öffentlichen Store wird durch das Pushen eines stabilen Tags oder eine ausdrückliche run_msstore-Anforderung ausgewählt; Beta-Flights verwenden run_msstore_flight.

Starten Sie den Workflow von main, um seine neuesten Korrekturen zu verwenden. Das Feld für den Release-Tag wählt den Quellcode eines Tags aus, der bereits im selben Repository existiert; es erstellt und pusht keinen Tag. Erstellen und pushen Sie den Tag zuerst (bei einem Fork im Fork-Repository), und geben Sie dann seinen genauen Namen einschließlich eines etwaigen v-Präfixes ein.

Aktuelle RC-Automatisierung

Der RC-Workflow ist .github/workflows/release-rc.yml.

Das Pushen eines neuen Tags vX.Y.Z-rc.N startet den Workflow. Bevor die Plattform-Builds beginnen, prüft er den Tag, die stabilen Basisversionen, die committete FOSS-Release-Version und den Tag-Commit. Ein fehlgeschlagener Lauf ohne veröffentlichtes GitHub-Prerelease wird wiederhergestellt, indem derselbe Tag gelöscht und auf dem korrigierten Commit neu erstellt wird. Wenn für den Tag bereits ein GitHub-Release vorhanden ist, führt der Workflow nur die Validierung durch; veröffentlichen Sie Änderungen unter der nächsten RC-Nummer. Verwenden Sie workflow_dispatch nur für kontrollierte Kanalwiederholungen oder zur Auswahl nicht standardmäßiger Kanäle.

Der Workflow verwendet nach Möglichkeit die Build-Jobs der stabilen Kanäle wieder und erstellt anschließend aus exakt den Linux-, macOS-, Windows-, Android- und Android-FOSS-Artefakten ein GitHub-Prerelease.

Außerdem veröffentlicht er Tester-Builds in den bereits verbundenen Store-gestützten Kanälen:

• Android-AAB standardmäßig in Google Play internal und offene Tests (beta). Bei manuellen RC-Läufen wählt play_track zusätzliche, kommagetrennte Test-Tracks aus; none bedeutet nur interne Tests. Mit run_play_testing=false werden Play-Uploads vollständig übersprungen.
• Watch-fähiges iOS-Archiv in TestFlight mit deaktivierter Einreichung zur App-Store-Prüfung. Der iOS-Job des RC wählt diese Variante aus, wartet auf die Verarbeitung und verteilt genau diesen Build an die konfigurierte externe Testgruppe.
• macOS-App-Store-Build in TestFlight mit deaktivierter Einreichung zur App-Store-Prüfung.
• Windows-MSIX zum Microsoft-Store-Flight Mindwtr Beta; manuelle Läufe können diesen Kanal deaktivieren.
• Pull Requests zur Aktualisierung des Flathub-Beta-Branches über den gemeinsamen Flathub-Workflow; manuelle Läufe können dies deaktivieren, wenn der Kanal noch nicht bereit ist.
• Sobald die GitHub-Prerelease-Artefakte vorhanden sind, erstellt und prüft der Workflow AUR mindwtr-beta-bin, veröffentlicht die exakten Dateien PKGBUILD und .SRCINFO im AUR und verifiziert den entfernten Git-Head.
• Aktualisierungen der Beta-APT-/RPM-Repositorys, nachdem das GitHub-Prerelease vorhanden ist; manuelle Läufe können sie deaktivieren.

Der stabile release.yml bleibt der Workflow für stabile Releases. Er ist so geschützt, dass Tags für Vorabversionen keine ausschließlich stabilen Kanäle wie Google Play Production, Microsoft Store, Snap Stable, Linux-APT-/RPM-Repositorys, Flathub Stable, AUR Stable, Scoop, winget, Homebrew oder Chocolatey veröffentlichen.

Der wiederverwendbare iOS-Workflow trennt die Watch-Einbindung (include_watch) vom reinen TestFlight-Routing (testflight_only). Für Ad-hoc-Aufrufer sind beide Eingaben standardmäßig false. Der RC-Workflow aktiviert beide und erzeugt so einen Watch-fähigen TestFlight-Build, ohne die Production-Version im App Store zu ändern. Der stabile Workflow aktiviert Watch und lässt das reine TestFlight-Routing deaktiviert, sodass ein einziges Archiv zur App-Store-Prüfung eingereicht und über TestFlight verteilt wird. Für eine manuelle stabile Wiederherstellung wird run_ios_appstore ausgewählt; es gibt keinen separaten Watch-Upload-Job.

Flathub Beta erfordert den Beta-Branch und Berechtigungen in flathub/tech.dongdongbh.mindwtr. Stabile Releases veröffentlichen das AUR-Paket mindwtr-bin nach einer Prüfung in einem sauberen Container und einer Eigentumsprüfung über release.yml. Das aus dem Quellcode gebaute Paket mindwtr wird von der Community gepflegt und ist nicht Teil des Release-Prozesses. RC-Builds veröffentlichen mindwtr-beta-bin mit denselben Sicherheitsprüfungen über update-aur-beta.yml. Wenn das AUR Pushes während einer Wartung deaktiviert, führen Sie diesen Kanal nach der Freigabe erneut aus.

Da ein Upload in einen Play-Test-Track einen Android-versionCode verbraucht, benötigt jeder RC mit Play-Upload einen neuen versionCode. Der RC-Workflow ermittelt diesen Code einmal, bevor die Android-Builds beginnen. Anschließend verwenden der Play-Build und der Android-FOSS-Build dieselbe Vorabprüfungsausgabe und laufen parallel. Der Workflow lädt ein AAB hoch und weist allen konfigurierten Test-Tracks denselben versionCode zu. Der aktuelle endgültige Stable-Ablauf sollte ebenfalls einen neuen Production-Upload mit höherem versionCode verwenden, oder ein künftiger Stable-Promotion-Workflow sollte den bereits getesteten Play-Build hochstufen. Taggen Sie kein endgültiges Stable-Release mit einem Android-versionCode, der bereits zu Play hochgeladen wurde, sofern der Stable-Workflow nicht gelernt hat, diesen vorhandenen Build hochzustufen.

Interne Tests verwenden dasselbe reguläre AAB ohne Profiling-Freigabe und denselben versionCode wie offene Tests. RC-Releases weisen diesen einen Upload standardmäßig internal und beta zu; stabile Releases weisen einen Upload production, beta und internal zu. Es gibt weder ein separates internes AAB noch einen zusätzlichen internen Versionscode. Die regulären APK- und AAB-Builds bleiben getrennt. Früher hochgeladene Profiling-Builds zählen weiterhin zum aktuellen höchsten Versionscode in Play.

Zeitplan

Kanäle mit längerer Prüfzeit benötigen Vorlauf. Verwenden Sie diesen Standardzeitplan:

Tag	Aktion
T-7 bis T-5	Feature Freeze. Nur Fehlerbehebungen, Versionshinweise, Metadaten und Release-Blocker sind zulässig.
T-5	Release-Branch erstellen, ./scripts/bump-version.sh vX.Y.Z-rc.1 ausführen, RC-spezifische Versionshinweise wie docs/release-notes/X.Y.Z-rc.1.md erzeugen und vX.Y.Z-rc.1 taggen, damit release-rc.yml die aktivierten Testerkanäle beliefert.
T-4	Smoke-Tests der Kanalartefakte ausführen, sobald geprüfte Builds verfügbar werden. Nur Blocker beheben.
T-3	GitHub-Prerelease aus release-rc.yml bestätigen, Flathub-Beta-PR und die AUR-Aktualisierung von mindwtr-beta-bin prüfen, wenn diese Workflow-Eingaben aktiviert waren, und den RC für Tester ankündigen.
T-2 bis T-1	Rückmeldungen triagieren. rc.2 nur bei Blockern erstellen. Nichtblocker wandern in den nächsten Zyklus.
Veröffentlichungstag	vX.Y.Z taggen, überall stabil veröffentlichen und alle vorhandenen dauerhaften Testkanäle ebenfalls auf die stabile Version aktualisieren.
T+1 bis T+2	Abstürze, GitHub-Issues, Discord, Store-Rückmeldungen und Downstream-Paketberichte beobachten. Bei Bedarf mit dem nächsten Patch-Tag korrigieren, etwa v1.1.1 nach v1.1.0.

Blocker-Schwelle für rc.2

Erstellen Sie nur bei einem der folgenden Blocker einen weiteren RC:

• Absturz beim Start
• Datenverlust oder Datenbeschädigung
• Beschädigung oder reproduzierbarer Fehler der Synchronisierung
• Fehler bei Installation, Aktualisierung, Signierung, Entitlements oder Paketierung
• Defekte Erfassung, Aufgabenerstellung, Aufgabenbearbeitung oder Aufgabenerledigung
• Defekte Migration von der vorherigen stabilen Version
• Schwere plattformspezifische Regression auf einem unterstützten Kanal

Alles andere wartet auf das nächste geplante Release oder einen späteren Patch. So wird der zweiwöchentliche Zug nicht zu einer endlosen Beta-Schleife.

Erforderliche RC-Smoke-Gates

Jeder Vertriebskanal ist eine andere Laufzeit. Der RC ist erst bereit, wenn das Artefakt jedes RC-Kanals in einer möglichst kanalgetreuen Umgebung probeweise gestartet wurde, soweit CI oder lokale Tests dies zulassen.

Mindestens prüfen:

• exakt das Artefakt starten, das Benutzer erhalten
• eine Aufgabe erstellen, bearbeiten, erledigen und löschen
• prüfen, ob Erfassung oder Schnelleingabe geöffnet und gespeichert werden kann
• prüfen, ob die App vorhandene Daten aus der vorherigen stabilen Version lesen kann
• prüfen, ob die Synchronisierungseinstellungen ohne Absturz geöffnet werden
• gegebenenfalls Updater-, Store- oder Sandbox-spezifisches Startverhalten prüfen
• prüfen, dass Protokolle keine fatalen Startfehler zeigen

Behalten Sie für Kanäle mit früheren Fehlern kanalspezifische Gates bei:

• FOSS-APK und Play-APK/-AAB sind getrennte Abhängigkeitsmengen
• Flatpak muss innerhalb der Flatpak-Laufzeit starten
• AUR-Pakete müssen vor der Veröffentlichung in einem sauberen Arch-Container gebaut werden
• MSIX-/Microsoft-Store-Pakete dürfen bei Tray-, Tastenkürzel- oder Sandbox-beschränkten Fähigkeiten nicht hart fehlschlagen
• App-Store- und TestFlight-Builds müssen die erforderlichen Entitlements beibehalten

Ankündigung für Tester

Die RC-Ankündigung sollte kurz und handlungsorientiert sein:

• Version und Kanallinks
• wichtigste benutzerseitige Änderungen
• bekannte Risiken oder besonders zu testende Bereiche
• genauer Rückmeldepfad: GitHub-Issue, Discord-Kanal oder E-Mail
• Hinweis, dass dies ein Release Candidate und keine Funktionsvorschau ist

---

Ablauf für stabile Releases

1. Stellen Sie sicher, dass main den vorgesehenen Release-Zustand hat, und committen Sie zunächst alle Vorabarbeiten.
   • Wenn die vorherige Version bereits veröffentlicht ist, legen Sie Folgekorrekturen bis zur Vorbereitung der nächsten Patch-Version unter docs/release-notes/unreleased.md ab und verlinken Sie sie aus CHANGELOG.md, zum Beispiel v0.9.1 nach v0.9.0.
2. Heben Sie die Version an mit:

./scripts/bump-version.sh 0.x.y

Dies aktualisiert die Versionen der Workspace-Pakete und erhöht den Android-versionCode.

Wenn Google Play durch RC- oder Tester-Uploads bereits einen höheren versionCode hat, übergeben Sie diesen Höchstwert vor dem Taggen an das Skript zur Versionsanhebung:

ANDROID_REMOTE_MAX_VERSION_CODE=85 ./scripts/bump-version.sh 0.x.y

Das Skript schreibt in apps/mobile/app.json einen nachverfolgten Wert oberhalb des Play-Höchstwerts, sodass Release-Tag, GitHub-APK und reproduzierbare Downstream-Build-Rezepte dieselben Android-Metadaten sehen. Die CI für stabile Releases lehnt weiterhin reine CI-Überschreibungen von versionCode ab; korrigieren Sie die Quellmetadaten vor dem Taggen, statt sich auf eine nicht nachverfolgte Workflow-Änderung zu verlassen.

3. Führen Sie vor dem Taggen die harten Release-Gates aus:
   • Typ-/Test-Gate:
     • bun run test
     • bun run typecheck
     • bun run native:test
   • FOSS-/statisches Gate:
     • git diff vPREV..HEAD -- apps/mobile/package.json prüfen
     • F-Droid-/FOSS-Konfigurationsdateien prüfen (apps/mobile/plugins/android-manifest-fixes.js, apps/mobile/scripts/, .github/workflows/release-android-foss.yml, config/izzyonandroid.yml)
     • python3 scripts/ci/repair-package-lock.py --check apps/desktop/package-lock.json ausführen
   • CloudKit-Schema-Gate:
     • synchronisierte Schemadateien mit dem vorherigen Tag vergleichen
     • wenn ein neues CloudKit-gestütztes Feld oder ein neuer Datensatztyp hinzugefügt wurde, das Produktionsschema vor dem Release aktualisieren/bereitstellen
4. Versionshinweise und Metadaten vorbereiten oder aktualisieren:
   • docs/release-notes/<version>.md
   • docs/release-notes/google-play/<version>.txt
   • metadata/*/release_notes.txt
   • metadata/*/changelogs/<androidVersionCode>.txt
   • metadata/metadata.json
   • apps/desktop/src-tauri/linux/Mindwtr.metainfo.xml
5. Aktualisieren Sie die öffentliche Dokumentation in der Quelle der Mindwtr-Webdokumentation, wenn sich Details des Release-/Dokumentationsprozesses geändert haben. Das GitHub Wiki wurde eingestellt; fügen Sie keine wiki/-Inhaltsseiten hinzu oder aktualisieren Sie sie, und führen Sie Git nicht in einem separaten .wiki-Checkout aus.
6. Prüfen Sie die entstandenen Versions- und Metadatenänderungen sorgfältig.
7. Committen Sie die Release-Vorbereitung:

git add -A
git commit -m "chore(release): v0.x.y"

8. Taggen Sie das Release:

git tag v0.x.y

9. Pushen Sie main und den Tag:

git push origin main --tags

10. Lassen Sie GitHub Actions die Plattformartefakte und alle Downstream-Paketierungsjobs veröffentlichen.

---

Gestaffelte Store-Rollouts

Stabile Releases erreichen Google Play und den Microsoft Store als gestaffelte Rollouts: 5 %, dann 20 %, 50 % und 100 %. Der Workflow Manage Store Rollout (rollout.yml) schaltet pro täglichem Lauf höchstens eine Stufe weiter, ein Rollout bleibt also mehrere Tage offen. Jeder Store erlaubt nur ein offenes Produktions-Rollout, daher muss das vorherige abgeschlossen oder angehalten sein, bevor das nächste stabile Tag gepusht wird; sonst schlagen die Veröffentlichungs-Jobs für Play und den Microsoft Store fehl und es entsteht kein GitHub-Release. Siehe Store-Rollouts für den Zeitplan, die manuellen Aktionen und das Anhalten.

---

Windows-Codesignierung

Der Release-Workflow ist für die Authenticode-Signierung von Windows-Builds über SignPath Foundation vorbereitet; derzeit ist jedoch kein veröffentlichter Download als signiert bestätigt. Sobald das Release-Zertifikat und die SignPath-Artefaktkonfiguration bereit sind, führt der Signierblock in .github/workflows/release-windows.yml pro Release zwei Signierrunden aus, und die Reihenfolge ist entscheidend:

1. tauri build --no-bundle hält bei der losen mindwtr.exe an, die zuerst signiert wird. Das NSIS-Installationsprogramm bettet eine eigene Kopie dieser Binärdatei ein; ein vor dem Signieren gebündeltes Installationsprogramm würde also auf jedem Rechner eine unsignierte EXE ablegen. Die signierte EXE fließt außerdem in das portable ZIP und das MSIX-Layout ein.
2. tauri bundle baut anschließend das Installationsprogramm um die signierte EXE herum, und mindwtr-setup.exe wird in einer zweiten Runde signiert.

Jede Runde ist eine eigene SignPath-Einreichung eines ZIPs mit genau einer Datei. Die Richtlinie release-signing verlangt daher zwei manuelle Freigaben pro Release, jeweils mit 30 Minuten Zeitlimit, bevor der Build fehlschlägt. Die Runden lassen sich nicht zusammenlegen: Das Installationsprogramm existiert erst, wenn die EXE signiert ist. Sowohl der stabile als auch der RC-Workflow rufen diesen Job auf, ein RC-Tag kostet also dieselben zwei Freigaben.

Der gesamte Block ist daran gebunden, dass das Repository dongdongbh/Mindwtr ist, die Repository-Variable SIGNPATH_SIGNING_ENABLED auf true steht, beide SignPath-Secrets gesetzt sind und ein Tag vorliegt. Forks, Pull Requests und Dispatch-Läufe ohne Tag erzeugen bewusst unsignierte Builds. Die Variable ist der Hauptschalter: Ist sie nicht gesetzt, werden die Signierschritte stillschweigend übersprungen und das Release erscheint unsigniert — ohne fehlschlagende Prüfung, die darauf hinweist.

Vor dem nächsten signierten Release muss die Artefaktkonfiguration in der SignPath-Oberfläche an die zwei Einreichungen mit je einer Datei angepasst werden. Das ist eine Aufgabe der Maintainer außerhalb dieses Repositories — die Workflow-Änderung allein genügt nicht — und sie entwertet den früheren Testsignierlauf, der die alte einzelne Einreichung mit beiden Dateien genutzt hat.

---

Vor dem Taggen

Prüfen Sie mindestens:

• Versionshinweise sind vorhanden und entsprechen den tatsächlichen Änderungen
• Paketversionen sind im gesamten Monorepo abgestimmt
• apps/mobile/release-version.json enthält bei einem RC-Tag die vollständige RC-Version
• Android-versionCode wurde erhöht
• Desktop-Paket-Lockdatei besteht repair-package-lock.py --check
• FOSS-Konfiguration entfernt weiterhin gesperrte Berechtigungen und behält nur beabsichtigte bei
• CloudKit-gestütztes Schema hat sich nicht geändert, oder das Produktionsschema wurde zuerst aktualisiert
• Änderungen an Store-/Release-Metadaten sind beabsichtigt und je Plattform begrenzt
• Kategorien der mobilen Stores in den Konsolen sind weiterhin korrekt: Google Play Productivity > Task Management und primäre App-Store-Kategorie Productivity
• Gebietsschemainhalte für Google Play halten die API-Grenze von 500 Zeichen ein
• die SignPath-Artefaktkonfiguration passt zum aktuellen Windows-Signierablauf mit zwei Einreichungen
• kein Produktions-Rollout des vorherigen stabilen Releases ist bei Google Play oder im Microsoft Store noch offen; schließen Sie es zuerst ab oder halten Sie es an

Prüfen Sie bei größeren Releases außerdem:

• Desktop-Updater-Metadaten
• Metadaten mobiler Stores/Fastlane-Eingaben
• Änderungen der Dokumentationswebsite für benutzerseitige Funktionen in der Quelle der Mindwtr-Webdokumentation
• Smoke-Test der backendübergreifenden Synchronisierung mit einem kleinen Ausgangsdatensatz: Hinzufügen, Aktualisieren, Löschen und Anhangsübertragung sollten zwischen Cloud, WebDAV-/Dateisynchronisierung und allen für den Release-Tester verfügbaren plattformnativen Backends konvergieren; eine zweite Synchronisierung sollte keine neuen Konflikte melden

---

Versionshinweise

Versionierte Versionshinweise befinden sich in docs/release-notes/.

Richtlinien:

• Zusammenfassung am Anfang benutzerorientiert halten
• wichtige Korrekturen/Funktionen zuerst aufführen
• wichtige Commits auflisten, wenn hilfreich
• für RCs docs/release-notes/X.Y.Z-rc.N.md oder docs/release-notes/vX.Y.Z-rc.N.md verwenden und die vollständige RC-Version in die erste Überschrift aufnehmen; docs/release-notes/X.Y.Z.md für das endgültige stabile Release reservieren
• bei stabilen Releases muss die erste Zeile genau # Mindwtr X.Y.Z oder # Mindwtr vX.Y.Z lauten; release.yml lehnt andere Überschriften ab
• Google-Play-Kurztexte unter docs/release-notes/google-play/ bei Bedarf abstimmen
• metadata/*/release_notes.txt für App-Store-Versionshinweise aktualisieren
• neue Android-Changelog-Datei unter metadata/*/changelogs/<versionCode>.txt hinzufügen
• Microsoft-Store-Versionshinweise in metadata/metadata.json auf dasselbe Release abstimmen
• obersten AppStream-Eintrag in apps/desktop/src-tauri/linux/Mindwtr.metainfo.xml hinzufügen oder aktualisieren

---

Prüfungen nach dem Release

Nach dem Pushen des Tags:

• Erstellung des GitHub-Releases prüfen
• prüfen, ob die erwarteten Desktop-/Mobilgeräte-Artefakte angehängt sind
• gegebenenfalls Erfolg storespezifischer Workflows prüfen
• Updater-/Downloadflächen stichprobenartig gegen die neue Version prüfen
• prüfen, ob Stable auch in vorhandenen dauerhaften Testkanälen veröffentlicht wurde, damit Tester beim neuesten Build bleiben

---

Haltung zu Rollbacks

Wenn ein fehlerhaftes Release erkannt wird:

• weitere Tags stoppen, bis die Fehlerursache verstanden ist
• ein schnelles vorwärts korrigierendes Release dem Umschreiben der veröffentlichten Historie vorziehen
• Versionshinweise zur korrigierenden Patch-Version eindeutig halten

---

Verwandte Seiten

• Entwicklerleitfaden
• Docker-Bereitstellung
• Cloud-Bereitstellung
• Versionshinweise des Repositorys
• Semantic Versioning
• GitHub-Prereleases
• Google-Play-Test-Tracks
• Apple TestFlight
• Flathub-Beta-Repository
• Microsoft-Store-Paket-Flights