Releases

Cada artefacto compilado a partir de este repositorio tiene una entrada correspondiente en la página de Releases de GitHub. Esa página es la fuente autorizada de qué se ha publicado, cuándo y qué ha cambiado.

Dónde encontrar los releases

Todos los releases — apps web, la API y apps nativas — se listan en github.com/jonot-io/jonot/releases.

Convenciones de etiquetado

Apps nativas — etiquetas de versión semántica, enviadas manualmente por el ingeniero que corta el release:

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

Apps web y API — marcadores continuos con marca de tiempo creados automáticamente después de cada despliegue de producción exitoso:

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

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

Los releases de artefactos nativos se activan al enviar una etiqueta que coincida con el prefijo del artefacto. El flujo de trabajo de CI compila, firma y publica en la tienda correspondiente, y luego crea un Release de GitHub con los binarios adjuntos.

Para cortar un release:

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

Sustituye host por android-kiosk o android-desk según corresponda, y actualiza la versión para que coincida con la entrada versionName / libs.versions.toml de la app.

Cada Release de GitHub para una app nativa incluye:

• android-kiosk / android-desk — AAB firmado, mapeo de ProGuard y el registro de cambios de la Play Store (whatsnew-en-US.txt).
• host — .deb, .rpm, SHA256SUMS y SHA256SUMS.asc (firmado con GPG).

SPAs web y API

Los pushes a main se despliegan automáticamente en el entorno development. Producción se promueve moviendo a la fuerza una etiqueta de release móvil al commit deseado y enviándola:

# Publicar todo (las nueve SPAs + API):
git tag -f release <sha> && git push -f origin release

# Publicar solo la API:
git tag -f release-api <sha> && git push -f origin release-api

# Publicar una única SPA (p. ej. admin):
git tag -f release-admin <sha> && git push -f origin release-admin

La etiqueta paraguas release publica las nueve SPAs y la API en un único push, evitando el límite de GitHub que suprime CI cuando se envían más de tres etiquetas a la vez. Los nombres de etiqueta no reconocidos hacen fallar el paso de resolución en lugar de desplegar en silencio.

Se crea un marcador de release web-<app>-r… o api-r… después de cada despliegue de producción exitoso, y se etiqueta como --prerelease para que no desplace la insignia nativa de “Latest release” de la versión semántica. Estos marcadores son el registro de cambios autorizado — registran lo que se publicó, no son puertas de control.

El release de la API también adjunta un recurso migrations.txt que lista cada archivo de migración de D1 presente en ese commit, para que puedas responder “¿se publicó la migración N?” desde la interfaz de Releases.

Notas de la versión

Las notas de la versión se generan automáticamente en GitHub a partir de los títulos de los pull requests fusionados entre la etiqueta de release anterior y la actual. Los prefijos de Conventional Commits (feat:, fix:, perf:, …) en los títulos de PR agrupan visualmente los cambios dentro del cuerpo de las notas.