86 lines
3.7 KiB
Markdown
86 lines
3.7 KiB
Markdown
<!-- file: docs/templates/005-RELEASE_PLAN.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# Pattern — plan de release
|
|
|
|
## Usage
|
|
|
|
Ce pattern aide un projet gouverné par PGR à construire un plan de release suffisamment précis pour piloter plusieurs tranches sans transformer le plan en journal d'activité. Il complète `alpha.1` et [`210-WORKFLOW.md`](../rules/210-WORKFLOW.md) ; il n'impose ni le titre exact des sections, ni un nombre fixe de prereleases.
|
|
|
|
Un petit changement qui ne nécessite pas de plan dédié n'a pas à instancier ce pattern.
|
|
|
|
## Contrat minimal
|
|
|
|
Un plan utile doit permettre de comprendre :
|
|
|
|
- d'où part la release et quelle mission elle doit rendre vraie ;
|
|
- ce qui est acquis, ouvert, inclus et explicitement hors-scope ;
|
|
- comment les risques, validations et smokes importants seront traités ;
|
|
- comment le travail est découpé actuellement et quels signaux imposeraient un REPLAN ;
|
|
- **où et quand la release sera clôturée** : documentation durable, `CHANGELOG`, `ROADMAP`, prompt/handoff suivant, plan et publication ;
|
|
- si l'horizon de roadmap doit être revu avant la fermeture et, si oui, à quel moment ou selon quel déclencheur.
|
|
|
|
## Forme candidate
|
|
|
|
```markdown
|
|
# Plan X.Y.Z — <mission courte>
|
|
|
|
## Statut et sources
|
|
|
|
Baseline, prompt, rapports ou corpus réellement autoritaires.
|
|
|
|
## Mission
|
|
|
|
Résultat attendu de la release.
|
|
|
|
## État acquis et questions ouvertes
|
|
|
|
Décisions déjà établies et points qui doivent encore être instruits.
|
|
|
|
## Scope et hors-scope
|
|
|
|
Frontières fonctionnelles, techniques et documentaires.
|
|
|
|
## Stratégie de validation
|
|
|
|
Gates, smokes et preuves importantes ; renvois vers la matrice plutôt que copie exhaustive.
|
|
|
|
## Trajectoire prévisionnelle
|
|
|
|
Responsabilité attendue de chaque tranche. Le forecast reste révisable.
|
|
|
|
## Déclencheurs de REPLAN
|
|
|
|
Signaux qui obligeraient à recalculer le travail restant.
|
|
|
|
## Clôture et transition
|
|
|
|
- réconciliation documentaire durable : <tranche/moment> ;
|
|
- entrée CHANGELOG candidate/finale : <tranche/moment> ;
|
|
- revue/mise à jour ROADMAP : <tranche/moment> ;
|
|
- prompt ou handoff de reprise : <tranche/moment ou cible encore ouverte> ;
|
|
- fermeture du plan : <tranche/moment> ;
|
|
- promotion stable et vérification post-tag : <mécanisme>.
|
|
|
|
## Revue d'horizon
|
|
|
|
- état : <non nécessaire / requise / horizon volontairement ouvert> ;
|
|
- raison : <pourquoi> ;
|
|
- moment ou déclencheur : <quand> ;
|
|
- sorties autorisées : <étendre / laisser ouvert / différer-pause / objectif accompli>.
|
|
```
|
|
|
|
## Règles d'adaptation
|
|
|
|
Le plan doit rester proportionné. Une responsabilité déjà possédée par une règle, une matrice ou une étude est référencée plutôt que recopiée. Les résultats détaillés des gates restent dans `history/`.
|
|
|
|
La rubrique `Clôture et transition` est un contrat d'attribution des responsabilités, pas l'obligation d'exécuter tous les travaux en fin de release. Une documentation directement liée à une fonctionnalité continue d'évoluer dans la tranche qui la modifie.
|
|
|
|
La rubrique `Revue d'horizon` peut simplement indiquer qu'aucune revue n'est nécessaire parce que la roadmap s'étend déjà suffisamment. Si la prochaine version n'est pas décidée, cette rubrique doit l'assumer explicitement plutôt que fabriquer une roadmap.
|
|
|
|
PGR n'impose pas un journal de révisions systématique dans le plan. Un REPLAN met à jour les parties devenues fausses et le delta/history correspondant conserve la preuve du changement.
|
|
|
|
## Critère de sortie
|
|
|
|
Le plan est prêt lorsqu'il autorise le développement sans laisser ambiguës les responsabilités de fermeture, les validations majeures ni le devenir de l'horizon macro. Après stable, abandon ou supersession, il devient une référence historique de la release.
|