Wij maken een van de tools op deze pagina. We hebben geprobeerd de andere te beschrijven op basis van waarvoor ze zijn gebouwd, niet op basis van waar ze tekortschieten, en de sectie over ons eigen product zegt duidelijk wie het niet zou moeten gebruiken.
De drie categorieën
Gehoste widget en pagina
Je schrijft items in hun editor, zij hosten de pagina en geven je een in-app widget. Het snelst op te starten, en de items leven op hun infrastructuur, niet op de jouwe. Beamer en AnnounceKit zijn de duidelijkste voorbeelden.
Feedbacksuite met changelog erbij
De changelog is een module naast functiestemming, een publieke roadmap en een feedback-inbox. De moeite waard als je de hele lus van één leverancier wilt, te groot als je alleen release notes wilt publiceren. Canny, Frill en Featurebase horen hier.
Gegenereerd vanuit je repository
De changelog ontstaat uit commits, pull requests of issues in plaats van met de hand getypt te worden. Het loopt van een bestand gebouwd in de CI tot een opgesteld, gecontroleerd, gepubliceerd item. git-cliff en github-changelog-generator zitten aan het bestandsuiteinde; LaunchNotes, Released en ons eigen product aan het gepubliceerde uiteinde.
In één oogopslag
| Tool | Type | Ideaal voor |
|---|---|---|
| Beamer | Gehoste widget | Vanmiddag nog een in-app paneel met nieuws live zetten, zonder ontwikkeltijd. |
| AnnounceKit | Gehoste widget | Hetzelfde, met meer aandacht voor wie welke aankondiging te zien krijgt. |
| Canny | Feedbacksuite | Teams die functiestemming en een publieke roadmap willen, met de changelog als laatste stap van die lus. |
| Frill | Feedbacksuite | Kleinere teams die hetzelfde model als Canny willen, maar lichter. |
| LaunchNotes | Vanuit de repository | Grotere organisaties die aankondigingen over teams heen afstemmen, vaak rond Jira. |
| Released | Vanuit de repository | Teams die in Jira leven en de changelog uit issues willen laten maken zonder Jira te verlaten. |
| git-cliff | Bestandsgenerator | Open-sourceprojecten die een CHANGELOG.md willen die in de CI wordt gebouwd uit conventional commits, zonder iets gehost. |
| Changeloop | Vanuit de repository | Teams die het item willen laten opstellen op basis van samengevoegde pull requests en het daarna met hun eigen frontend renderen vanuit een JSON-feed. |
Hoe te kiezen
- Begin bij waar de changelog moet verschijnen. Moet het aanvoelen als deel van je product, dan zal een gehoste pagina waarnaar je linkt je teleurstellen, hoe goed de editor ook is; dan wil je een herstylbare widget of een feed die je zelf rendert. Volstaat een gelinkte pagina, dan zijn gehoste tools veel minder werk.
- Vraag jezelf dan af wie de items schrijft. Is het antwoord 'degene die het samenvoegde', kies dan iets dat je repository leest, want alles anders voegt een handmatige stap toe precies wanneer iedereen het druk heeft. Is het antwoord iemand van productmarketing die vanuit een releaseplan werkt, dan past een editor beter en zal automatisering vanuit de repository alleen maar in de weg zitten.
- Vraag jezelf dan af of je de rest van de lus nodig hebt. Functiestemming en een publieke roadmap zijn echt nuttig en echt een grotere verplichting. Een suite kopen om de changelog-module is hoe teams eindigen met betalen voor vier dingen om er één te gebruiken.
- Controleer ten slotte wat er met je items gebeurt als je vertrekt. Een tool die ze exporteert als gestructureerde data verschilt sterk van een tool waarin ze op een gehoste pagina leven die je zou moeten scrapen.
Waar onze eigen tool past, en waar niet
Changeloop leest elke samengevoegde pull request, stelt een naar de gebruiker gericht item op, filtert dependency-updates en refactors eruit, en bewaart het concept voor controle. Wat wordt gepubliceerd, gaat naar een publieke JSON-feed met een roadmap-feed ernaast, plus een widget van twee regels en een gehoste pagina als terugvaloptie. De feed is de kern: het idee is dat je je changelog rendert met je eigen componenten in je eigen product.
Kies dit niet als:
- Je releases niet uit je repositories komen. Het maakt concepten van merges of, in pushmodus, van pushes, dus een team dat buiten een Git-werkproces levert heeft niets te controleren.
- Je functiestemming wilt en een roadmap waarop je gebruikers stemmen. Er is een roadmap-feed, maar die wordt gevoed door gelabelde issues, niet door stemmen. Daarvoor is een feedbacksuite de juiste categorie.
- Je een verfijnde editor en een gehoste pagina als hoofdproduct wilt. De gehoste pagina bestaat als terugvaloptie, en tools die daar helemaal omheen gebouwd zijn, doen dat beter.
- Je in je eentje een open-sourceproject beheert en gewoon een CHANGELOG.md in de repository wilt. Gebruik git-cliff, dat is gratis en daar precies voor gemaakt.
Veelgestelde vragen
Hebben we echt een tool nodig?
Een tijdje niet. Een Markdown-bestand, of een pagina op je eigen site, is een prima changelog en kost niets. Een tool begint zich terug te betalen wanneer het schrijven van items de stap is die wordt overgeslagen, of wanneer je dezelfde items op drie plekken wilt zonder drie kopieën bij te houden.
Kunnen we later van een van deze tools af?
Dat hangt volledig af van of de items er weer als gestructureerde data uitkomen. Vraag dat voordat je begint, niet erna: het is de enige vraag op deze lijst waarvan een verkeerd antwoord duur uitpakt, want een changelog is een groeiend archief, en twee jaar ervan overtypen is geen project dat iemand goedkeurt.
En ze schrijven met een AI-assistent?
De meeste van deze tools stellen inmiddels ergens op de achtergrond op met een model. Belangrijker dan dat is wat het model te zien krijgt. Een tool die alleen een commit-onderwerp ziet, kan alleen dat onderwerp herschrijven; een tool die de titel en beschrijving van de pull request ziet, heeft genoeg om de wijziging te beschrijven in termen van wat die voor de gebruiker doet. Vraag wat de invoer is, niet of er AI in zit.
Verder lezen: Changelog-automatisering, en haar grenzen, over welke van de vier stappen automatisch zou moeten zijn.
Degene die de feed vooropstelt
Opgesteld op basis van je samengevoegde pull requests, bewaard voor controle, gepubliceerd naar een JSON-feed die je zelf rendert. Gratis voor één repository, geen kaart.
Gratis starten