Rédiger les notes de version

Cette skill couvre la rédaction d'un article complet de notes de version pour une version du SDK tldraw publiée.

Localisation

Tous les fichiers de version se trouvent dans apps/docs/content/releases/.

Processus

1. Identifier la version

Obtenez le numéro de version et trouvez la version GitHub :

gh release view v4.3.0

Cela affiche la date de version, le tag et les notes de version de GitHub.

2. Trouver tous les PRs dans la version

Listez les PRs fusionnés entre la version précédente et celle-ci :

# Trouver les commits entre les versions
git log v4.2.0..v4.3.0 --oneline --merges

# Ou utiliser gh pour lister les PRs
gh pr list --state merged --base main --search "merged:2024-01-01..2024-02-01"

3. Récupérer les détails des PRs

Pour chaque PR, obtenez les détails complets :

gh pr view <PR_NUMBER> --json title,body,labels,author,baseRefName

Cherchez :

• La section ### Release notes dans le corps du PR
• La section ### API changes dans le corps du PR
• Les labels indiquant la catégorie (api, bugfix, improvement, etc.)
• Si « breaking » apparaît dans le PR

Important : Incluez uniquement les PRs dont baseRefName est main. Les PRs fusionnés dans des branches de fonctionnalité (p. ex. default-shape-customization) ne sont pas encore publiés — ils seront inclus quand la branche de fonctionnalité elle-même est fusionnée à main.

4. Trouver les versions de patch

Listez les versions de patch pour cette version mineure :

gh release list | grep "v4.3"

Pour chaque version de patch, trouvez ses PRs :

git log v4.3.0..v4.3.1 --oneline --merges

5. Rédiger l'article

Créez apps/docs/content/releases/vX.Y.0.mdx en suivant le guide de style.

1. Rédigez le frontmatter avec la version, les dates et les mots-clés
2. Rédigez une introduction de 1-2 phrases résumant les points forts
3. Créez des sections en vedette pour les grandes fonctionnalités et les changements non rétrocompatibles
4. Listez les changements d'API, les améliorations et les corrections de bugs
5. Ajoutez des sections de version de patch si applicable
6. Ajoutez les liens de version GitHub

6. Vérifier

Vérifiez que :

• Tous les PRs significatifs sont représentés
• Les liens des PRs sont corrects et correctement formatés
• Les contributeurs de la communauté sont crédités
• Les changements non rétrocompatibles sont marqués avec 💥
• Les sections sont dans le bon ordre

Références

• Guide de style : Consultez ../shared/release-notes-guide.md pour des conseils sur ce que doit contenir un article de notes de version et comment le formater.