Release

Ogni artefatto costruito da questo repository ha una voce corrispondente nella pagina GitHub Releases. Quella pagina è la fonte autorevole per cosa è stato pubblicato, quando e cosa è cambiato.

Dove trovare le release

Tutte le release — app web, l’API e le app native — sono elencate su github.com/jonot-io/jonot/releases.

Convenzioni sui tag

App native — tag di versione semantica, inviati manualmente dall’ingegnere che effettua la release:

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

App web e API — marcatori progressivi con timestamp creati automaticamente dopo ogni distribuzione di produzione riuscita:

• apps/api (Worker): api-r<YYYYMMDD-HHMM>-<sha7> — es. api-r20260523-1542-abc1234
• SPA web (9 app): web-<app>-r<YYYYMMDD-HHMM>-<sha7> — es. web-admin-r20260523-1542-abc1234

App native (host, android-kiosk, android-desk)

Le release per gli artefatti nativi vengono attivate inviando un tag corrispondente al prefisso dell’artefatto. Il workflow CI compila, firma e pubblica sullo store appropriato, quindi crea una GitHub Release con i binari allegati.

Per effettuare una release:

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

Sostituisci host con android-kiosk o android-desk a seconda dei casi, e aggiorna la versione in modo da corrispondere alla voce versionName / libs.versions.toml dell’app.

Ogni GitHub Release per un’app nativa include:

• android-kiosk / android-desk — AAB firmato, mapping ProGuard e il changelog del Play Store (whatsnew-en-US.txt).
• host — .deb, .rpm, SHA256SUMS e SHA256SUMS.asc (firmato GPG).

SPA web e API

I push su main vengono distribuiti automaticamente nell’ambiente development. La produzione viene promossa forzando lo spostamento di un tag di release mobile sul commit desiderato e inviandolo:

# Distribuisci tutto (tutte e nove le SPA + API):
git tag -f release <sha> && git push -f origin release

# Distribuisci solo l'API:
git tag -f release-api <sha> && git push -f origin release-api

# Distribuisci una singola SPA (es. admin):
git tag -f release-admin <sha> && git push -f origin release-admin

Il tag ombrello release distribuisce tutte e nove le SPA e l’API in un unico push, aggirando il limite di GitHub che sopprime la CI quando vengono inviati più di tre tag contemporaneamente. Nomi di tag non riconosciuti fanno fallire il passaggio di risoluzione anziché distribuire silenziosamente.

Un marcatore di release web-<app>-r… o api-r… viene creato dopo ogni distribuzione di produzione riuscita ed etichettato --prerelease così da non sostituire il badge nativo “Latest release” semver. Questi marcatori sono il changelog autorevole — registrazioni di ciò che è stato distribuito, non cancelli di approvazione.

La release dell’API allega anche un asset migrations.txt che elenca ogni file di migrazione D1 presente in quel commit, così puoi rispondere alla domanda “la migrazione N è stata distribuita?” direttamente dall’interfaccia Releases.

Note di rilascio

Le note di rilascio sono generate automaticamente da GitHub a partire dai titoli delle pull request unite tra il tag di release precedente e quello attuale. I prefissi Conventional Commit (feat:, fix:, perf:, …) nei titoli delle PR raggruppano visivamente le modifiche all’interno del corpo delle note.