Générateur de changelog
Collez vos commits bruts et obtenez 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 transforme une pile de messages de commit en notes de version sur lesquelles une personne peut agir. Vous collez des notes en vrac, des commits conventionnels ou des puces produit, et nous rangeons chaque ligne dans Added, Changed, Fixed, Security, Removed, Deprecated et Breaking, nous retirons les préfixes parasites et nous réécrivons les lignes cryptiques en puces claires. Nous construisons ensuite un markdown façon Keep a Changelog, nous ébauchons un court résumé avec un titre proposé, et nous lançons une vérification SemVer qui vous prévient quand votre incrément de version et vos notes semblent se contredire. Une passe de QA signale les puces en double, les notes de migration manquantes et une formulation de sécurité trop faible avant la publication. Tout tourne dans votre navigateur, rien de ce que vous saisissez n'est envoyé.
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
Ce générateur de changelog transforme des messages de commit bruts en notes de version sur lesquelles un lecteur peut agir. Vous collez vos commits ou vos notes en vrac, et nous les rangeons dans Added, Changed, Fixed, Security, Removed, Deprecated et Breaking, puis nous nettoyons la formulation et construisons le markdown de release prêt à publier. Nous vérifions votre incrément de version par rapport à ce que vous avez écrit, signalons tout écart, et vous remettons un court résumé à coller sur une page de release ou dans un corps GitHub. Une passe de QA repère les puces en double et les notes de migration manquantes avant la mise en ligne. Tout tourne dans votre navigateur, rien de ce que vous saisissez n'est envoyé.
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.