From de647a6ff89028e893e6b5d5a9587181535c3779 Mon Sep 17 00:00:00 2001 From: Antoine Van Elstraete Date: Tue, 8 Sep 2026 21:04:08 +0200 Subject: [PATCH] docs: ajouter la politique de versionnage et releases dans AGENTS.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Ajoute la section 13 « Versionnage et releases » qui documente : - Politique semver en phase 0.x (patch / minor / 1.0.0) - Règle absolue : pas de tag sans validation en environnement réel - Procédure de release en 7 étapes - Cohérence tag Git / pyproject.toml / CHANGELOG.md --- AGENTS.md | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index f98fe9e..757fd87 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -326,3 +326,47 @@ Un changement est considéré comme **terminé** lorsque : - Le *handoff* distingue clairement : - Ce qui a été vérifié localement (ex. : tests unitaires, linter). - Ce qui nécessite encore une vérification manuelle (ex. : tests d'intégration avec un serveur CalDAV réel). + +--- + +## 13. Versionnage et releases + +### Politique de versionnage + +Le projet suit **Semantic Versioning** (semver.org v2.0.0). Phase actuelle : `0.x` (pré-`1.0.0`). + +| Changement | Incrément | +|------------|----------| +| Défaut constaté au déploiement | Patch (`0.1.Z`) — correction rétrocompatible | +| Ajout ou cassure en phase `0.x` | Minor (`0.Y.0`) | +| Déploiement réel validé | `1.0.0` | + +### Règle absolue de validation + +**Aucune montée de version (tag + release) ne peut être effectuée +sans validation préalable en environnement réel.** Les tests automatisés et la revue de code +ne suffisent pas ; le correctif ou la fonctionnalité doit avoir été testé avec succès +sur le serveur de production (ou un environnement équivalent) avant de tagger. + +### Procédure de release + +1. **Valider en environnement réel** : le correctif ou la fonctionnalité est testé + sur le serveur de production. +2. **Mettre à jour `pyproject.toml`** : incrémenter le champ `version` à la nouvelle version. +3. **Mettre à jour `CHANGELOG.md`** : ajouter une entrée sous le format + [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) avec la nouvelle version et la date. +4. **Committer** : un commit `chore: monter en version x.y.z` regroupe + les mises à jour de `pyproject.toml` et `CHANGELOG.md`. +5. **Tagger** : créer un tag annoté `vx.y.z` sur le commit de version. +6. **Pousser le tag** : `git push origin vx.y.z`. +7. **Créer la release** sur Gitea avec le changelog correspondant. + +### Cohérence des versions + +Les trois sources de version doivent toujours être synchronisées au moment d'un tag : +- Le tag Git (`vx.y.z`) +- `pyproject.toml` (`version = "x.y.z"`) +- `CHANGELOG.md` (`## [x.y.z] - YYYY-MM-DD`) + +> **Rappel** : Ne jamais créer un tag sans avoir d'abord mis à jour +> `pyproject.toml` et `CHANGELOG.md`. -- 2.47.3