41 lines
1.2 KiB
Markdown
41 lines
1.2 KiB
Markdown
# Plan de release — 4NK_template (projet)
|
||
|
||
## Objectifs
|
||
|
||
- Version documentée, testée, sécurisée
|
||
- Processus reproductible et traçable
|
||
|
||
## Préparation
|
||
|
||
- CI verte: lint/tests/doc/security‑audit/release‑guard
|
||
- Docs à jour (INDEX, guides impactés)
|
||
- Version/Changelog/Tag alignés
|
||
|
||
## Lancement
|
||
|
||
- Tagging: `vX.Y.Z` ou `vX.Y.Z-wip.N`
|
||
- Notes de release (résumé, changements majeurs, impacts)
|
||
|
||
### Stratégies de merge (tags → branches cibles)
|
||
|
||
- Tag sur `main` (latest):
|
||
- Aligner `TEMPLATE_VERSION` et `CHANGELOG.md` sur la branche de travail
|
||
- Taguer `vX.Y.Z` puis merger la branche (PR) vers `main`
|
||
- Si flux local (CI désactivée): appliquer les agents en local avant tag/push
|
||
|
||
- Tag sur `develop` (pré‑release/wip):
|
||
- Utiliser `vX.Y.Z-wip.N` pour itérer
|
||
- Merger régulièrement vers `develop`; rebase/merge planifié vers `main` pour la release finale
|
||
|
||
### Cas particuliers
|
||
|
||
- Merge de tag existant vers `main` ou `develop`:
|
||
- Créer une PR contenant l’alignement version/changelog correspondant au tag
|
||
- Appliquer les agents (localement si CI neutre) puis merger
|
||
|
||
## Post‑lancement
|
||
|
||
- Suivi issues/retours
|
||
- Corrections critiques
|
||
- Mise à jour de la roadmap
|