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 »

Avant de lancer le script, CHANGELOG.md doit déjà contenir une section exacte pour la version cible :

## [X.Y.Z] - YYYY-MM-DD
Fenêtre de terminal
./scripts/release.sh <X.Y.Z>

Le script :

  1. Refuse de tourner hors main ou avec un worktree sale.
  2. Vérifie que la section CHANGELOG.md existe déjà pour la version.
  3. Bump package.json, le package-lock.json racine, adapters/inbound/web/ui/package.json et le lockfile UI.
  4. Lance npm run lint et npm test.
  5. Crée le commit release signé DCO chore: release vX.Y.Z.

Le script ne crée pas de tag.

Étape 2 — Pousser

Section intitulée « Étape 2 — Pousser »
Fenêtre de terminal
git push origin main
git tag vX.Y.Z
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 les SBOM de release pour la racine, l’UI et cortex-lite.
  4. Génère le tarball arka-deck-X.Y.Z.tar.gz avec les fichiers attendus (dist/, bin/, docs/, LICENSE, NOTICE, README.md, README.fr.md, CHANGELOG.md, SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, AGENT-INSTALL.md, AGENT-INSTALL.fr.md, ROADMAP.md, .env.example, sbom/, package.json).
  5. Audite le tarball (scripts/check-release-tarball.mjs) — refuse les fichiers internes leakés et les SBOM manquants.
  6. Calcule la SHA256.
  7. Crée la GitHub Release avec le tarball, la SHA256, les SBOM 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é : ajouter la section CHANGELOG.md, lancer ./scripts/release.sh X.Y.Z+1, pousser main, créer git tag vX.Y.Z+1, puis pousser le tag.

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 »