docs: politique de versionnage et releases dans AGENTS.md
Co-authored-by: Antoine Van Elstraete <antoine@van-elstraete.net> Co-committed-by: Antoine Van Elstraete <antoine@van-elstraete.net>
This commit was merged in pull request #3.
This commit is contained in:
44
AGENTS.md
44
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`.
|
||||
|
||||
Reference in New Issue
Block a user