Processus de Release Chorus

Guide étape par étape pour publier une nouvelle version de Chorus.

Prérequis

• gh CLI est authentifié (gh auth status)
• L'arborescence de travail est propre (git status)
• Vous êtes sur la branche develop

Étapes

1. Récupérer le remote et identifier les modifications depuis la dernière release

# Récupérer les tags et branches distants pour que les références locales soient à jour
git fetch --tags origin

# Trouver le tag de la release précédente
git tag -l 'v*' --sort=-version:refname | head -5

# Lister les commits depuis le tag précédent sur develop
git log --oneline v<PREV>..develop

# Passer en revue chaque commit pour identifier les changements dignes du CHANGELOG
git show --stat <commit-hash>

2. Rédiger le CHANGELOG et obtenir l'approbation de l'utilisateur

En fonction des commits identifiés à l'étape 1, rédigez la nouvelle section CHANGELOG et présentez-la à l'utilisateur pour examen. Utilisez cette structure :

## [X.Y.Z] - YYYY-MM-DD

### Added
- **Feature name**: Description of what was added.

### Changed
- **Area**: Description of what changed.

### Fixed
- **Bug name**: Description of what was fixed.

### Plugin
- Plugin version changes if applicable.

---

Règles :

• Inclure uniquement les commits après le tag de la release précédente
• Grouper par Added / Changed / Fixed / Deprecated / Removed / Plugin
• Omettre les groupes vides
• Chaque entrée doit commencer par un label en gras suivi d'une description concise
• Séparer de la section de la release précédente avec ---

IMPORTANT : Après la rédaction, montrez le contenu du CHANGELOG et le numéro de version proposé à l'utilisateur. Ne procédez PAS tant que l'utilisateur n'a pas explicitement approuvé. L'utilisateur peut demander des modifications au libellé, au numéro de version ou au groupement.

3. Écrire CHANGELOG.md (sur develop)

Après approbation de l'utilisateur, écrivez le contenu approuvé dans CHANGELOG.md — ajoutez la nouvelle section en haut, sous l'en-tête # Changelog et au-dessus de la section de la release précédente.

4. Mettre à jour la version dans package.json (sur develop)

# Éditer le champ "version" de package.json
# p. ex., "0.1.0" → "0.1.1"

Suivez semver :

• patch (0.1.0 → 0.1.1) : corrections de bugs, ajouts mineurs
• minor (0.1.0 → 0.2.0) : nouvelles fonctionnalités, modifications non-rompantes
• major (0.1.0 → 1.0.0) : modifications rompantes

5. Committer sur develop et ouvrir une PR vers main

# Committer la préparation de la release sur develop
git add CHANGELOG.md package.json
git commit -m "chore: bump version to vX.Y.Z and update CHANGELOG"
git push origin develop

# Ouvrir une PR de develop → main
gh pr create --base main --head develop \
  --title "chore: release vX.Y.Z" \
  --body "Release vX.Y.Z — version bump and CHANGELOG update."

Attendez que les CI passent, puis fusionnez la PR :

# Fusionner la PR (utiliser le numéro de PR retourné ci-dessus)
gh pr merge <PR_NUMBER> --merge

6. Créer une release GitHub avec tag (sur main)

Après la fusion de la PR dans main :

# Récupérer le dernier main pour que le tag cible le bon commit
git fetch origin main

gh release create vX.Y.Z \
  --target main \
  --title "vX.Y.Z" \
  --notes "$(cat <<'EOF'
<paste only the new version's CHANGELOG section here, without the ## header>
EOF
)"

Important : Les --notes ne doivent contenir que le contenu de la nouvelle version, pas la totalité du fichier CHANGELOG.

7. Synchroniser develop avec main et vérifier

# Récupérer le commit de fusion dans develop
git checkout develop
git pull origin develop

# Confirmer que le tag existe
git tag -l 'vX.Y.Z'

# Confirmer que la release est visible
gh release view vX.Y.Z

Checklist

• [ ] git fetch --tags origin exécuté — les tags locaux sont à jour
• [ ] git log v<PREV>..develop examiné — aucun commit oublié
• [ ] Brouillon du CHANGELOG présenté à l'utilisateur et approuvé
• [ ] CHANGELOG.md écrit avec le contenu approuvé
• [ ] Version de package.json mise à jour
• [ ] Changements commités et poussés sur develop
• [ ] PR de develop → main créée, CI réussie, et fusionnée
• [ ] gh release create avec tag ciblant main
• [ ] Notes de release contenant uniquement la section de la nouvelle version
• [ ] develop synchronisé avec main après fusion
• [ ] gh release view confirme que tout est correct