Versões

Todos os artefactos compilados a partir deste repositório têm uma entrada correspondente na página de Releases do GitHub. Essa página é o registo autoritativo do que foi publicado, quando e o que mudou.

Onde encontrar as versões

Todas as versões — aplicações web, a API e aplicações nativas — estão listadas em github.com/jonot-io/jonot/releases.

Convenções de tags

Aplicações nativas — tags de versão semântica, enviadas manualmente pelo engenheiro que cria a versão:

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

Aplicações web e API — marcadores contínuos com data/hora, criados automaticamente após cada implementação de produção bem-sucedida:

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

Aplicações nativas (host, android-kiosk, android-desk)

As versões de artefactos nativos são acionadas ao enviar uma tag correspondente ao prefixo do artefacto. O fluxo de trabalho de CI compila, assina e publica na loja apropriada, e depois cria uma Release do GitHub com os binários anexados.

Para criar uma versão:

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

Substitua host por android-kiosk ou android-desk conforme apropriado, e atualize a versão para corresponder à entrada versionName / libs.versions.toml na aplicação.

Cada Release do GitHub para uma aplicação nativa inclui:

• android-kiosk / android-desk — AAB assinado, mapeamento ProGuard, e o registo de alterações da Play Store (whatsnew-en-US.txt).
• host — .deb, .rpm, SHA256SUMS, e SHA256SUMS.asc (assinado com GPG).

SPAs web e API

Os envios para main são implementados automaticamente no ambiente de desenvolvimento. A produção é promovida ao mover à força uma tag de versão móvel para o commit pretendido e enviá-la:

# Publicar tudo (as nove SPAs + API):
git tag -f release <sha> && git push -f origin release

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

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

A tag guarda-chuva release publica as nove SPAs e a API num único envio, contornando o limite do GitHub que suprime a CI quando mais de três tags são enviadas de uma vez. Nomes de tags não reconhecidos fazem falhar o passo de resolução, em vez de implementar silenciosamente.

Um marcador de versão web-<app>-r… ou api-r… é criado após cada implementação de produção bem-sucedida e marcado como --prerelease, para não substituir o emblema de “Latest release” da versão semântica nativa. Estes marcadores são o registo de alterações autoritativo — registos do que foi publicado, não portões de controlo.

A versão da API também anexa um recurso migrations.txt que lista todos os ficheiros de migração D1 presentes nesse commit, para que possa responder “a migração N foi publicada?” a partir da interface de Releases.

Notas de versão

As notas de versão são geradas automaticamente pelo GitHub a partir dos títulos dos pull requests integrados entre a tag de versão anterior e a atual. Os prefixos de Conventional Commits (feat:, fix:, perf:, …) nos títulos dos PRs agrupam as alterações visualmente dentro do corpo das notas.