Versions

Chaque artefact construit à partir de ce dépôt a une entrée correspondante sur la page GitHub Releases. Cette page est le flux faisant autorité pour ce qui a été livré, quand, et ce qui a changé.

Où trouver les versions

Toutes les versions — applications web, l’API, et les applications natives — sont listées sur github.com/jonot-io/jonot/releases.

Conventions de tags

Applications natives — tags de version sémantique, poussés manuellement par l’ingénieur qui coupe la version :

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

Applications web et API — marqueurs continus horodatés créés automatiquement après chaque déploiement de production réussi :

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

Applications natives (host, android-kiosk, android-desk)

Les versions des artefacts natifs sont déclenchées en poussant un tag correspondant au préfixe de l’artefact. Le workflow CI construit, signe, et publie sur le magasin approprié, puis crée une GitHub Release avec les binaires attachés.

Pour couper une version :

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

Remplacez host par android-kiosk ou android-desk selon le cas, et augmentez la version pour correspondre à l’entrée versionName / libs.versions.toml de l’application.

Chaque GitHub Release pour une application native inclut :

• android-kiosk / android-desk — AAB signé, mapping ProGuard, et le journal des modifications du Play Store (whatsnew-en-US.txt).
• host — .deb, .rpm, SHA256SUMS, et SHA256SUMS.asc (signé GPG).

SPA web et API

Les poussées vers main se déploient automatiquement sur l’environnement de développement. La production est promue en forçant le déplacement d’un tag de version déplaçable vers le commit souhaité et en le poussant :

# Livrer tout (les neuf SPA + l'API) :
git tag -f release <sha> && git push -f origin release

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

# Livrer une seule SPA (par ex. admin) :
git tag -f release-admin <sha> && git push -f origin release-admin

Le tag parapluie release livre les neuf SPA et l’API en une seule poussée, contournant la limite de GitHub qui supprime la CI lorsque plus de trois tags sont poussés en même temps. Les noms de tags non reconnus font échouer l’étape de résolution plutôt que de se déployer silencieusement.

Un marqueur de version web-<app>-r… ou api-r… est créé après chaque déploiement de production réussi et marqué --prerelease afin de ne pas remplacer le badge « Dernière version » de la version sémantique native. Ces marqueurs sont le journal des modifications faisant autorité — des enregistrements de ce qui a été livré, pas des portails.

La version de l’API attache aussi un actif migrations.txt listant chaque fichier de migration D1 présent à ce commit, afin que vous puissiez répondre à « la migration N a-t-elle été livrée ? » depuis l’interface Releases.

Notes de version

Les notes de version sont générées automatiquement par GitHub à partir des titres des pull requests fusionnées entre le tag de version précédent et celui en cours. Les préfixes Conventional Commit (feat:, fix:, perf:, …) dans les titres des PR regroupent visuellement les changements au sein des notes.