Date : 2026-01-16 22:08
Workflow : breaking-setup.md
Organiser les rapports de breaking changes dans des sous-répertoires datés pour un meilleur tri chronologique et une organisation plus claire.
reports-breaking/
├── ctbase-0.17.0-2026-01-16-setup.md
├── PR-404-comment.md
├── GUIDE-ctbase-0.17.0.md
├── GUIDE-beta-versions.md
└── ... (tous les fichiers mélangés)
Problèmes :
- ❌ Fichiers mélangés dans un seul répertoire
- ❌ Difficile de trouver tous les fichiers d'une migration
- ❌ Pas de tri chronologique clair
- ❌ Nom de fichier long et répétitif
reports-breaking/
└── 2026-01-16-ctbase-0.17.0/
├── setup.md
├── PR-comment.md
├── README.md
├── GUIDE.md
└── ... (tous les fichiers de cette migration)
Avantages :
- ✅ Un répertoire par migration
- ✅ Tri chronologique automatique (YYYY-MM-DD)
- ✅ Noms de fichiers courts et clairs
- ✅ Facile de trouver tous les fichiers liés
- ✅ Facile d'archiver ou de supprimer une migration complète
Format : YYYY-MM-DD-{package}-{version}
Exemples :
2026-01-16-ctbase-0.17.02026-02-15-ctmodels-0.7.02026-03-20-ctparser-0.8.0
Tri lexicographique = Tri chronologique ! 🎉
Ajout d'une étape pour créer le répertoire de rapport :
- Générer le nom :
YYYY-MM-DD-{package}-{version} - Confirmer avec l'utilisateur
- Créer le répertoire :
mkdir -p reports-breaking/{dir} - Stocker le chemin :
REPORT_DIR="reports-breaking/{dir}"
Avant : reports-breaking/{package}-{version}-{date}-setup.md
Après : ${REPORT_DIR}/setup.md
Avantage : Nom de fichier court et clair
Avant : reports-breaking/PR-{pr_number}-comment.md
Après : ${REPORT_DIR}/PR-comment.md
Avantages :
- Nom plus court
- Pas besoin du numéro de PR dans le nom
- Toujours dans le bon répertoire
Avant : /breaking-action-plan reports-breaking/ctbase-0.17.0-2026-01-16-setup.md
Après : /breaking-action-plan reports-breaking/2026-01-16-ctbase-0.17.0
Avantage : Le second workflow reçoit un répertoire, pas un fichier
Chaque répertoire de migration contient :
- setup.md - Rapport de setup principal (obligatoire)
- PR-comment.md - Commentaire pour la PR (obligatoire)
- README.md - Vue d'ensemble du répertoire (optionnel)
- GUIDE.md - Guide des prochaines étapes (optionnel)
- Autres fichiers - Selon les besoins de la migration
Le workflow /breaking-action-plan devra être mis à jour pour :
- Accepter un répertoire au lieu d'un fichier
- Lire
${REPORT_DIR}/setup.md - Créer les fichiers de sortie dans
${REPORT_DIR}/
Exemple :
/breaking-action-plan reports-breaking/2026-01-16-ctbase-0.17.0Le workflow lira :
reports-breaking/2026-01-16-ctbase-0.17.0/setup.md
Et créera :
reports-breaking/2026-01-16-ctbase-0.17.0/action-plan.mdreports-breaking/2026-01-16-ctbase-0.17.0/phase-*.md- etc.
- Organisation : Un répertoire = une migration
- Chronologie : Tri automatique par date
- Clarté : Noms de fichiers courts
- Archivage : Facile de déplacer/supprimer une migration
- Navigation : Facile de trouver tous les fichiers liés
- Évolutivité : Peut contenir autant de fichiers que nécessaire
reports-breaking/
├── 2026-01-16-ctbase-0.17.0/
│ ├── setup.md
│ ├── PR-comment.md
│ ├── README.md
│ ├── action-plan.md
│ ├── phase-1-beta-versions.md
│ ├── phase-2-migrations.md
│ └── COMPLETE.md
│
├── 2026-02-15-ctmodels-0.7.0/
│ ├── setup.md
│ ├── PR-comment.md
│ └── action-plan.md
│
└── 2026-03-20-ctparser-0.8.0/
├── setup.md
└── PR-comment.md
Navigation facile : ls -la reports-breaking/ montre toutes les migrations par ordre chronologique !
- ✅ Workflow
breaking-setup.mdmis à jour - ⏳ Workflow
breaking-action-plan.mdà mettre à jour - ⏳ Tester avec une vraie migration
- ⏳ Documenter dans le README principal
Statut : ✅ Implémenté dans breaking-setup.md