Zum Inhalt springen
Jonot Docs

Releases

Jedes aus diesem Repository gebaute Artefakt hat einen entsprechenden Eintrag auf der GitHub-Releases-Seite. Diese Seite ist die maßgebliche Quelle dafür, was wann veröffentlicht wurde und was sich geändert hat.

Wo Sie Releases finden

Abschnitt betitelt „Wo Sie Releases finden“

Alle Releases — Web-Apps, die API und native Apps — sind unter github.com/jonot-io/jonot/releases aufgeführt.

Tag-Konventionen

Abschnitt betitelt „Tag-Konventionen“

Native Apps — semantische Versions-Tags, die der Ingenieur beim Erstellen des Releases manuell pusht:

  • apps/host (Desktop): host-v<semver> — z. B. host-v1.2.3
  • apps/native-kiosk: android-kiosk-v<semver> — z. B. android-kiosk-v1.4.0
  • apps/native-desk: android-desk-v<semver> — z. B. android-desk-v1.4.0

Web-Apps und API — zeitgestempelte, laufend aktualisierte Marker, die automatisch nach jedem erfolgreichen Produktions-Deploy erstellt werden:

  • apps/api (Worker): api-r<YYYYMMDD-HHMM>-<sha7> — z. B. api-r20260523-1542-abc1234
  • Web-SPAs (9 Apps): web-<app>-r<YYYYMMDD-HHMM>-<sha7> — z. B. web-admin-r20260523-1542-abc1234

Native Apps (host, android-kiosk, android-desk)

Abschnitt betitelt „Native Apps (host, android-kiosk, android-desk)“

Releases für native Artefakte werden durch das Pushen eines zum Präfix des Artefakts passenden Tags ausgelöst. Der CI-Workflow baut, signiert und veröffentlicht in den jeweiligen Store und erstellt anschließend ein GitHub-Release mit angehängten Binärdateien.

So schneiden Sie ein Release:

Terminal-Fenster
git tag host-v1.0.0
git push origin host-v1.0.0

Ersetzen Sie host je nach Bedarf durch android-kiosk oder android-desk, und erhöhen Sie die Version passend zum versionName- / libs.versions.toml-Eintrag der App.

Jedes GitHub-Release für eine native App enthält:

  • android-kiosk / android-desk — signierte AAB, ProGuard-Mapping und das Play-Store-Änderungsprotokoll (whatsnew-en-US.txt).
  • host — .deb, .rpm, SHA256SUMS und SHA256SUMS.asc (GPG-signiert).

Web-SPAs und API

Abschnitt betitelt „Web-SPAs und API“

Pushes auf main werden automatisch in die Umgebung development deployt. Produktion wird befördert, indem ein bewegliches Release-Tag zwangsweise auf den gewünschten Commit verschoben und gepusht wird:

Terminal-Fenster
# Alles ausliefern (alle neun SPAs + API):
git tag -f release <sha> && git push -f origin release


# Nur die API ausliefern:
git tag -f release-api <sha> && git push -f origin release-api


# Eine einzelne SPA ausliefern (z. B. admin):
git tag -f release-admin <sha> && git push -f origin release-admin

Das Umbrella-Tag release liefert alle neun SPAs und die API in einem einzigen Push aus und umgeht damit das GitHub-Limit, das CI unterdrückt, wenn mehr als drei Tags gleichzeitig gepusht werden. Nicht erkannte Tag-Namen lassen den Auflösungsschritt fehlschlagen, statt stillschweigend zu deployen.

Ein web-<app>-r…- oder api-r…-Release-Marker wird nach jedem erfolgreichen Produktions-Deploy erstellt und mit --prerelease markiert, damit er das native Semver-„Latest release“-Abzeichen nicht verdrängt. Diese Marker sind das maßgebliche Änderungsprotokoll — Aufzeichnungen dessen, was ausgeliefert wurde, keine Freigabetore.

Dem API-Release wird außerdem eine Datei migrations.txt beigefügt, die jede in diesem Commit vorhandene D1-Migrationsdatei auflistet, sodass Sie die Frage „Wurde Migration N ausgeliefert?“ direkt aus der Releases-Oberfläche beantworten können.

Versionshinweise

Abschnitt betitelt „Versionshinweise“

Versionshinweise werden von GitHub automatisch aus den Titeln der zusammengeführten Pull Requests zwischen dem vorherigen und dem aktuellen Release-Tag erzeugt. Conventional-Commit-Präfixe (feat:, fix:, perf:, …) in PR-Titeln gruppieren Änderungen visuell innerhalb der Hinweise.