Aller au contenu
Arka Platform

Procédure de release

arka-deck est distribué exclusivement via GitHub Releases (ADR 0004). Le package npm reste volontairement privé.

Prérequis

Section intitulée « Prérequis »
  • Droits push sur main (mainteneur).
  • Token GitHub avec permissions write sur releases.
  • Environnement local propre (git status propre).
  • Tous les gates CI verts sur la branche à publier.

Étape 1 — Préparer la version

Section intitulée « Étape 1 — Préparer la version »
Fenêtre de terminal
./scripts/release.sh <X.Y.Z>

Le script :

  1. Vérifie la cohérence des numéros de version (package.json, adapters/inbound/web/ui/package.json).
  2. Met à jour le CHANGELOG.md (section [Unreleased] → [X.Y.Z] - <date>).
  3. Crée le commit chore(release): vX.Y.Z.
  4. Crée le tag vX.Y.Z signé.

Étape 2 — Pousser

Section intitulée « Étape 2 — Pousser »
Fenêtre de terminal
git push origin main
git push origin vX.Y.Z

Le push du tag déclenche automatiquement le workflow .github/workflows/release.yml.

Étape 3 — Workflow de release automatique

Section intitulée « Étape 3 — Workflow de release automatique »

Le workflow :

  1. Refait l’intégralité des gates CI.
  2. Build la dist + l’UI.
  3. Génère le tarball arka-deck-X.Y.Z.tar.gz avec les fichiers attendus (dist/, bin/, docs/, LICENSE, NOTICE, README.md, CHANGELOG.md, SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, AGENT-INSTALL.md, ROADMAP.md, .env.example, package.json).
  4. Audite le tarball (scripts/check-release-tarball.mjs) — refuse les fichiers internes leakés.
  5. Calcule la SHA256.
  6. Crée la GitHub Release avec le tarball, la SHA256 et le CHANGELOG.

Étape 4 — Annonce

Section intitulée « Étape 4 — Annonce »
  • Mettre à jour le README badge version si nécessaire.
  • Annoncer la release sur GitHub Discussions / canaux communauté.
  • Vérifier le déploiement éventuel du site doc statique (si activé).

Cas de hotfix

Section intitulée « Cas de hotfix »

Pour un patch urgent sur la version X.Y.Z :

  1. Brancher depuis le tag : git checkout -b hotfix/X.Y.Z+1 vX.Y.Z.
  2. Appliquer le fix.
  3. PR vers main.
  4. Une fois mergé : ./scripts/release.sh X.Y.Z+1 puis git push origin vX.Y.Z+1.

Signature et provenance

Section intitulée « Signature et provenance »
  • DCO sign-off sur chaque commit (vérifié en CI).
  • GitHub Actions attestations sur les artefacts release (provenance).
  • Sigstore / cosign : prévu mais pas encore actif (cf. ROADMAP.md).

Versionnement (SemVer)

Section intitulée « Versionnement (SemVer) »

Le projet suit Semantic Versioning :

  • MAJOR : breaking change publique (par exemple v2.0.0 = retrait TUI).
  • MINOR : ajouts rétro-compatibles (par exemple nouvel addon).
  • PATCH : corrections rétro-compatibles.

Les versions des sous-packages (addons/cortex-lite/) peuvent diverger volontairement (par exemple 0.1.0 pour un module pre-release).

Voir aussi

Section intitulée « Voir aussi »