Générateur de changelog
Colle tes commits bruts et obtiens des sections de release triées, le markdown du changelog, une vérification SemVer et une passe de QA rapide avant de publier.
Ce générateur de changelog prend la pile de commit messages que tu préfères ne pas lire à la main et la transforme en release notes sur lesquelles une personne peut agir. Colle des notes en vrac, des conventional commits ou des bullets produit, et il range chaque ligne dans Added, Changed, Fixed, Security, Removed, Deprecated et Breaking, retire les préfixes bruyants et réécrit les one-liners cryptiques en bullets clairs. Il construit ensuite un markdown façon Keep a Changelog, ébauche un court résumé avec un titre, et lance une vérification SemVer qui te prévient quand ton bump de version et tes notes se contredisent. Tout tourne dans ton navigateur, rien de ce que tu colles ne quitte la page.
100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.
Tri des notes de release, vérification SemVer et rédaction de changelog
Écrire un changelog, c'est la corvée par excellence. Juste avant une release, ce que je veux c'est livrer, pas plisser les yeux sur cinquante commit messages en me demandant lesquels un humain regardera un jour. Du coup j'ai bricolé ça pour avaler la moitié chiante. Tu colles tes commits ou tes notes en vrac. L'outil les range dans Added, Changed, Fixed, Security, Removed, Deprecated et Breaking, nettoie la formulation pour la personne qui va lire, sort le markdown de release, revérifie ton bump de version par rapport à ce que tu as vraiment écrit, et te tend un court résumé à coller sur une page de release ou dans un body GitHub. Tout tourne dans ton navigateur. Rien de ce que tu colles ne quitte la page.
Colle tes vraies notes de commits ou tes bullets d'issues, puis relis ce qui ressort et corrige tout ce qui sonne faux. Un changelog est censé dire à la personne qui upgrade ce qui a changé pour elle. Il n'est pas là pour recracher ce que tu as tapé dans git.
Un générateur de changelog explique l'impact, pas juste les commits
Un générateur de changelog gagne sa place quand il transforme un mur de commit messages en release notes qu'un humain peut lire. Un changelog, c'est la mémoire du projet. Et je l'ai appris à mes dépens : un mur de noms de branches ne te dit rien six mois plus tard. Ce que tu veux vraiment savoir est plus simple : qu'est-ce qui a changé, est-ce que ça me concerne, est-ce qu'un truc va me mordre après l'upgrade ? Les commit messages sont un bon point de départ. Le hic, c'est qu'ils sont écrits pour toi, en langage d'implémentation. Une release note retourne ça. Elle regroupe les choses par qui ressent le changement et réécrit les one-liners cryptiques en bullets qu'un humain peut lire. Surtout, elle sort la sécurité, les suppressions et les breaking changes du tas pour qu'ils ne disparaissent pas entre deux corrections de typo.
Donne-lui ce que tu as sous la main. Notes en vrac, conventional commits, une liste de bullets produit, peu importe. L'outil lit chaque ligne, retire les préfixes bruyants, construit un markdown façon Keep a Changelog, ébauche un court résumé, puis te prévient quand ton numéro de version et tes notes semblent se contredire, avant que tu publies. Moi je m'appuie dessus pour des petits outils et des mises à jour de plugins WordPress. Pour les posts de release SaaS et les GitHub releases aussi. Même les notes de déploiement que personne en dehors de l'équipe ne lira jamais.
Comment choisir les bonnes sections de changelog
Voilà comment je les découpe. Added, c'est du tout neuf. Changed, c'est un truc qui marchait déjà mais qui se comporte différemment maintenant. Fixed, ce sont les bugs. Security a son propre bac exprès, parce que les gens lisent ces lignes autrement et qu'une équipe ops doit parfois patcher dans l'urgence. La paire qui fait trébucher tout le monde, c'est Removed contre Deprecated. Removed veut dire que c'est parti aujourd'hui. Deprecated veut dire que ça marche encore, mais que tu le mets en sursis. Et Breaking ? Ça va tout en haut, fort, avant tout le reste. Quelqu'un survole, le rate, et voilà une mauvaise après-midi pour vous deux.
- Classification lit les préfixes comme feat, fix, security, docs, change, remove et breaking, puis classe chaque ligne là où elle doit aller.
- Markdown te file une release note que tu peux vraiment relire. Tu gardes les sections vides ou tu les vires, à toi de voir.
- Release summary ébauche un court paragraphe destiné aux utilisateurs, plus un titre à coller en haut.
- SemVer check te pousse du coude quand ton réglage d'impact et les notes ne collent pas.
- Release QA te tanne sur les migration notes, la formulation sécurité, et les bullets en double que tu n'as sans doute pas remarqués.
SemVer et communication de release
SemVer, au fond, c'est une promesse de compatibilité. Major dit « ça va casser quelque chose, lis attentivement ». Minor dit « du neuf, mais ton install existante va bien ». Patch dit « corrections de bugs, upgrade et passe à autre chose ». Ton changelog doit tenir cette promesse. Tague une release en patch, puis glisse en douce un breaking change, et les gens cessent de faire confiance à tes numéros de version. Et une fois cette confiance perdue, franchement, je ne crois pas qu'on la regagne un jour vraiment : les gens lisent chaque release sur la défensive. Même histoire quand tu enterres un correctif de sécurité dans la pile Fixed. La seule équipe qui devait réagir vite passe juste à côté.
Bonnes habitudes de changelog
- Regroupe par qui ressent le changement, pas par l'ordre dans lequel les commits ont atterri.
- Remplace le verbe interne pour que la bullet dise ce qui a vraiment changé pour le lecteur.
- Fusionne les doublons. Jette tout ce qui ne compte qu'à l'intérieur de l'historique git.
- Mets les breaking changes et les étapes de migration en tête, devant les sections de routine.
- Garde les lignes de sécurité justes et précises. Et ne les dramatise pas non plus : le calme vaut mieux que la peur.
Questions fréquentes
Est-ce que chaque commit doit apparaître dans le changelog ?
Surtout pas. Un changelog est une liste triée sur le volet, pas un git log avec des étapes en plus. Saute les petits refactors et les passes de formatage. Saute les bumps de dépendances que personne ne remarquera jamais, sauf si l'un d'eux change vraiment quelque chose pour un utilisateur, un mainteneur, ou le risque de la release. Si une ligne ne fait bouger l'aiguille pour personne, laisse-la dehors.
Quelle est la différence entre Changed et Fixed ?
Changed veut dire que ça marchait comme prévu avant et que ça se comporte différemment maintenant, parce que tu as choisi de le modifier. Fixed veut dire que c'était cassé et que tu l'as remis d'aplomb. Pourquoi la distinction compte-t-elle ? Une ligne Changed dit à quelqu'un de revérifier que son workflow fait toujours ce qu'il attend. Une ligne Fixed dit juste qu'un mal de crâne a disparu.
Est-ce que ça peut remplacer la relecture de release ?
Non, et je n'en aurais pas envie. Vois ça comme le premier jet qui t'épargne la partie pénible. Il te faut quand même une vraie personne pour vérifier que la formulation est juste, que les migration notes ne laisseront personne en plan, que le langage de sécurité est correct, que chaque bullet a mérité sa place. L'outil trie et nettoie. Ce qui part en prod, ça reste sur toi.
Quel format un changelog doit-il suivre ?
Honnêtement, choisis-en un et tiens-t'y. La plupart des gens atterrissent sur Keep a Changelog : un bloc par version, chacun estampillé d'une date, et dedans les sections familières Added / Changed / Fixed / Removed. Ça se lit propre et c'est prévisible. Inventer ton propre format rend surtout les upgrades plus durs à survoler plus tard.
Qu'est-ce que le versioning sémantique ?
C'est le schéma MAJOR.MINOR.PATCH que tu as vu partout. Bump MAJOR quand tu casses la compatibilité. Bump MINOR quand tu ajoutes des fonctionnalités qui ne cassent rien, et PATCH quand tu ne fais que corriger des bugs. Tout l'intérêt, c'est que quelqu'un jette un œil au numéro et jauge en gros à quel point il doit être nerveux à l'idée d'upgrader.