Voorbeelden van release notes: 5 ingevulde notes om te kopiëren
Deze voorbeelden van release notes dekken vijf veelvoorkomende releasesituaties: een nieuwe functie in een SaaS-app, een hotfix, een tekst voor de app stores, een gedateerde API-wijziging en een bedrijfsbrede overstap op een nieuwe IT-tool. Product-, engineering- en IT-teams kunnen elk van deze release notes als tekst kopiëren, en bij elk voorbeeld hoort een bijbehorende pdf.
Wat goede voorbeelden van release notes gemeen hebben: een openingsregel die product, versie, releasedatum en platform vastlegt.
Updates in de app stores: geef elke fix een eigen regel, met het oude symptoom en het nieuwe gedrag.
Sterk tegenover zwak: sterke regels beschrijven een voordeel voor de gebruiker, zwakke regels sommen interne onderdelen op.
Vage regels: de voorbeeldnotes en changelogvoorbeelden op deze pagina noemen elke fix afzonderlijk. Zoek je een lege opzet, open dan het sjabloon voor release notes.
Wat een goed voorbeeld van release notes kenmerkt
Elk voorbeeld in de galerij verwijst op nummer naar deze zeven criteria.
- Kopregel met versie en datum. Begin met de productnaam, het versie- of buildnummer, de releasedatum en, als dat per platform verschilt, waar de release is uitgerold (web, iOS, API). Wie deze regel mist, kan niet zien of de note geldt voor de versie die hij gebruikt.
- Korte samenvatting bovenaan. Een tot drie zinnen vóór de lijst vertellen wie er geraakt wordt en hoe. Zonder die zinnen belandt de lezer meteen tussen de opsommingstekens.
- Formulering vanuit het resultaat. Elke regel beschrijft iets wat de lezer wint of waar hij geen last meer van heeft ("Je kunt nu..."). Zwakke formuleringen sommen interne componenten op ("Pipeline voor zoekindexering geoptimaliseerd").
- Labels per type wijziging. Regels staan onder een typelabel, zoals Opgelost of Breaking, met gelijksoortige regels bij elkaar. Zonder label lezen een reparatie en een nieuwe functie hetzelfde.
- Concrete bugfixes als voor en na. Elke fix koppelt het symptoom waar iemand tegenaan liep aan hoe het product zich nu gedraagt, met één fix per regel. De zwakke versie houdt het bij één verzamelregel.
- Vereiste acties en breaking changes eerst. Alles wat de lezer moet doen staat bovenaan, samen met de deadline. Is er niets nodig, dan staat er "Geen actie vereist". Zwakke notes verstoppen een breaking change ergens halverwege de lijst.
- Bekende problemen en een plek voor hulp. Wat nog niet werkt, krijgt een workaround of de datum van de fix, en de slotregel verwijst naar documentatie of een supportcontact. Laat je dit weg, dan wek je de indruk dat er niets kapot is.

5 voorbeelden van release notes om over te nemen
Hier zijn vijf voorbeelden, één per type release, die wij rekenen tot de beste voorbeelden van release notes om van te lenen. Alle bedrijven erin zijn fictief.
Voorbeeld 1: lancering van een SaaS-functie
Voor een PM die één nieuwe functie aankondigt in een B2B-facturatieapp.

- Kopregel: Ledgerly 3.8 · 6 mei 2026 · Web · Growth- en Scale-abonnementen
- Nieuw: facturen zitten nu zelf achter hun betaling aan
- Samenvatting: Ledgerly kan nu betalingsherinneringen versturen volgens een schema dat jij instelt, zodat financeteams geen opvolgmails meer met de hand schrijven. Beschikbaar op de Growth- en Scale-abonnementen.
- Wat je nu kunt: stel tot 3 herinneringen per factuur in (bijvoorbeeld 3 dagen vóór de vervaldatum, op de vervaldatum en 7 dagen erna). Herinneringen stoppen automatisch zodra de betaling is geregistreerd. Elke herinnering gebruikt de huisstijl van je facturen.
- Zo gebruik je het: (1) Open Instellingen > Herinneringen. (2) Zet Automatische herinneringen aan. (3) Kies een schema of voeg je eigen schema toe. (4) Klik op Opslaan. Het schema geldt voor elke onbetaalde factuur.
- Jullie vroegen erom, wij bouwden het: functieverzoek #412 op het feedbackbord van Ledgerly (230 stemmen).
- Beschikbaarheid: wordt uiterlijk 20 mei 2026 uitgerold naar alle Growth- en Scale-accounts.
- Bekende beperking: herinneringen worden alleen in het Engels verstuurd. Meer talen staan gepland voor Q3 2026.
- Hulp nodig: help.ledgerly.example/reminders
Waarom het werkt: criteria 1, 2, 3, 4 en 7. De titel is het resultaat zelf.
Let op: de beperking tot Engels is die van Ledgerly. Vermeld de beperkingen van je eigen functie.
Pdf downloaden - Facturen zitten nu zelf achter hun betaling aan
Voorbeeld 2: update in de mobiele app stores
Een mobiele PM die de updatetekst voor beide app stores schrijft.

- Kopregel: Trailmate · Nieuw in versie 5.12 · 2 juni 2026 · iOS en Android
- Offline kaarten worden nu op de achtergrond gedownload, zodat je je telefoon kunt vergrendelen en kunt doorlopen.
- Nieuw: een tempolijn in de hoogtegrafiek laat zien waar je bij elke klim vaart minderde.
- Opgelost: je gps-track stopt niet meer als je halverwege een wandeling de camera opent.
- Opgelost: de Apple Watch-app toont afstanden nu in mijlen als je telefoon op mijlen staat.
- Slotregel: Bedankt voor de meldingen waarmee we dit konden oplossen. Vragen? support.trailmate.example
Met opsommingstekens en regeleinden komen de vier regels samen op 341 van de 500 tekens van Google Play.
Waarom het werkt: criteria 1, 2, 3, 4, 5 en 7. Elke fix noemt wat de wandelaar zag.
Let op: een vijfde regel kan de tekst over de limiet van 500 tekens van Google Play duwen.
Pdf downloaden - Nieuw in versie 5.12
Voorbeeld 3: patchrelease met bugfixes
Voor een supportlead die een live hotfix voor planningssoftware aankondigt.

- Kopregel: Rostra 2.14.1 hotfix · 18 juni 2026 · Web, iOS, Android
- Samenvatting: Deze hotfix lost twee problemen op die in 2.14.0 zijn ontstaan. De fix staat live voor elk account. Er is geen actie vereist.
- Opgelost: dienstruilingen die in de mobiele app waren goedgekeurd, verschenen pas na vernieuwen in het webrooster. Goedgekeurde ruilingen staan nu binnen 5 seconden op het web.
- Opgelost: overurenmeldingen gingen af bij 38 uur in plaats van 40 voor accounts waarvan de week op maandag begint. Meldingen gaan nu af bij 40 uur, en ten onrechte verstuurde meldingen zijn gewist.
- Getroffen gebruikers: accounts met maandag als eerste dag van de week die tussen 16 en 18 juni 2026 overurenmeldingen gebruikten.
- Oorzaak: de instelling voor het begin van de week werd in UTC gelezen in plaats van in de tijdzone van het account.
- Bekend probleem: CSV-exports van dienstruilingen tonen tijden nog in UTC. De fix komt in 2.14.2 op 25 juni 2026.
- Hulp nodig: support@rostra.example
Waarom het werkt: criteria 1, 2, 5, 6 en 7, met "Er is geen actie vereist" bovenaan.
Let op: de regel over de oorzaak. Houd die bij jou op één regel.
Pdf downloaden - Rostra 2.14.1 hotfix
Voorbeeld 4: wijziging van de API-versie
Een platformteam informeert integratoren over een gedateerde API-versie.

- Kopregel: Parcelo API versie 2026-07-01 · Uitgebracht op 1 juli 2026 · Actie vereist vóór 15 januari 2027
- Samenvatting: Versie 2026-07-01 verandert hoe tarieven prijzen teruggeven en hernoemt één veld. Je integratie blijft werken op de vastgezette versie tot je upgradet. Het v1-endpoint voor labels stopt op 15 januari 2027.
- Breaking:
GET /ratesgeeftamountterug als geheel getal in centen (1299) in plaats van als decimale string ("12.99"). - Breaking: het veld
carrierheet nucarrier_code. - Nieuw (niet-breaking):
estimated_delivery(ISO 8601-datum) bij elk tarief. - Verouderd:
POST /v1/labels, uitgefaseerd op 15 januari 2027. Gebruik in plaats daarvanPOST /v2/labels. - Zo upgrade je: (1) Stuur de header
Parcelo-Version: 2026-07-01mee in een testomgeving. (2) Deelamountdoor 100 overal waar je prijzen toont. (3) Vervangcarrierdoorcarrier_code. (4) Verplaats labelaanroepen naar/v2/labels. - Voor:
{"carrier": "UPS", "amount": "12.99"} - Na:
{"carriercode": "ups", "amount": 1299, "estimateddelivery": "2026-07-04"} - Hulp nodig: docs.parcelo.example/changelog/2026-07-01 en het kanaal #api in de ontwikkelaarscommunity van Parcelo.
Waarom het werkt: criteria 1, 2, 3, 4, 6 en 7. De deadline en de uitfaseringsdatum staan bovenaan.
Let op: de breaking wijziging van het type van amount. Geef bij elke typewijziging een fragment voor en na.
Pdf downloaden - Parcelo API versie 2026-07-01
Voorbeeld 5: uitrol van een interne IT-tool
Voor IT Operations die een tool aankondigt aan zo'n 420 medewerkers van Northwind Freight, een logistiek bedrijf.

- Kopregel: IT-release: wachtwoordmanager Vaultkey · Uitrol 7 juli tot 21 juli 2026 · Alle medewerkers
- Samenvatting: Vaultkey vervangt de gedeelde spreadsheet 'Team Passwords'. Iedereen stapt in drie golven over, en de spreadsheet wordt op 28 juli alleen-lezen.
- Uitrolgolven: Finance en HR op 7 juli, Operations en Dispatch op 14 juli, en alle anderen op 21 juli.
- Wat er voor jou verandert: de browserextensie van Vaultkey wordt automatisch geïnstalleerd op bedrijfslaptops. Teamkluizen vervangen de tabbladen van de spreadsheet. De spreadsheet wordt op 28 juli 2026 alleen-lezen en IT archiveert hem op 31 augustus 2026.
- Wat je moet doen (actie vereist binnen 2 dagen na jouw golf): (1) Accepteer de uitnodigingsmail van Vaultkey. (2) Stel een hoofdwachtwoord in van minstens 14 tekens. (3) Optioneel: installeer de mobiele app van Vaultkey.
- Bekend probleem: zet in Safari de extensie zelf aan via Instellingen > Extensies.
- Terugdraaien: IT bewaart de back-up van de spreadsheet tot 31 augustus 2026.
- Hulp nodig: het Slack-kanaal #it-help en het IT-spreekuur op dinsdag en donderdag om 14:00 uur.
- Verantwoordelijke: Priya Raman, IT Operations.
Waarom het werkt: criteria 1, 2, 3, 6 en 7. Elke actie heeft een deadline.
Let op: de data die in elke golf vastliggen. Schuift er een op, stuur de note dan opnieuw.
Pdf downloaden - IT-release: wachtwoordmanager Vaultkey
Zo pas je een voorbeeld van release notes aan
- Kies het voorbeeld uit de galerij dat het dichtst bij jouw type release ligt. Kies op type release: lancering van een functie, update in de app stores, hotfix, API-wijziging of interne uitrol. Past geen enkel voorbeeld, begin dan met het lege sjabloon voor release notes.
- Stem de diepgang af op de omvang van de wijziging. Grote lanceringen verdienen achtergrond en een afbeelding. Kleine aanpassingen kunnen samen in een kort overzicht, en een patch begint met wat hij oplost.
- Behoud het typelabel en de korte samenvatting. Houd deze twee velden aan bij elke omvang, ook als je al het andere schrapt.
- Herschrijf elke regel vanuit het resultaat. Vervang technische termen door het resultaat dat een gebruiker merkt.
- Beantwoord "raakt dit mij?" in de eerste zin. Noem wie er profiteert of wie actie moet ondernemen.
- Laat de feiten bevestigen door het team dat het bouwde. Vraag de engineers die het hebben uitgebracht om gedrag, abonnementen, platforms en versie te bevestigen voordat de note de deur uit gaat.
- Label de regel zodat lezers hem later terugvinden. Geef hem een datum, een type wijziging, een label voor het productonderdeel en een vaste URL, en gebruik bij elke release dezelfde opzet.
Wanneer je release notes nodig hebt
Grote releases die meerdere producten of enterprise-tenants beslaan, hebben notes het hardst nodig, omdat beheerders moeten filteren op product, platform en versie om te zien wat hen raakt. Kleinere releases hebben ze ook nodig: één nieuwe functie in een webapp (voorbeeld 1), of een hotfix waarvan de gebruikers willen weten of hun probleem is opgelost (voorbeeld 3).
Op mobiel en in API's gelden harde grenzen. Apple beperkt de updatetekst tot 4.000 tekens in de App Store, en Google staat 500 tekens toe op Google Play (voorbeeld 2). API-integratoren moeten van een wijziging horen zodra een deadline codewerk afdwingt (voorbeeld 4).
Interne tools tellen ook mee. De note vertelt supportmedewerkers, salesmedewerkers en systeemeigenaren wat er is veranderd, bij wie ze terechtkunnen en hoe terugdraaien werkt (voorbeeld 5).
Veelgemaakte fouten in release notes
- Schrijven in engineeringjargon of tickets letterlijk overnemen. Een regel als "Pipeline voor zoekindexering geoptimaliseerd", of een kale commitmelding, zegt niets over het werk van de lezer. Mensen haken af.
- Vage regels als "bugfixes en prestatieverbeteringen". Wie een bug heeft gemeld, ziet niet of die is opgelost, en support krijgt er weer een ticket bij.
- Breaking changes en verplichte stappen halverwege de lijst verstoppen. Als één opsommingsteken tussen vele valt een breaking change niet op, en integraties breken zodra de deadline verstrijkt.
- Een lang, ononderbroken log zonder samenvatting uitbrengen. Zonder samenvatting moeten lezers elke regel doornemen om te weten of er iets voor hen bij zit.
- Persoonlijkheid laten verhullen wat er veranderd is. Wie naar een wijziging zoekt, vindt die niet onder een slimme kop die geen functie noemt.
Sla de lege pagina over: neem het op
Teams die elke release demonstreren, kunnen die sessie opnemen en aan Hinto AI geven, waarvan het "What's New"-sjabloon een eerste versie van de note maakt. Hinto werkt met links van Loom, Zoom en YouTube, uploads in MP4, MOV en WebM, en schermopnames uit de eigen recorder in de webapp of de Chrome-extensie.
Tijdens het verwerken van de video herkent Hinto klikken op knoppen en schermwisselingen en haalt er screenshots en uitgeschreven stappen uit. Voor engineering kan een opgenomen sprintdemo een doorzoekbare lijst met bugfixes worden.
Een sectie die niet klopt, kun je markeren en opnieuw laten genereren, inclusief de afbeeldingen. De afgeronde note kan op een openbare pagina onder je eigen domein staan, in 50+ talen worden gemaakt of naar Intercom, Notion, Confluence, GitHub of GitLab gaan.
Veelgestelde vragen over release notes
Welke labels gebruik je in release notes?
Houd het bij zes: Nieuw, Verbeterd, Opgelost, Verouderd, Breaking en Bekend probleem. Door regels per label te groeperen springt elke lezer direct naar het deel dat hem aangaat. Zonder labels vallen fixes weg tussen nieuwe functies, en mist een gebruiker makkelijk de wijziging die hij nodig heeft.
Horen er screenshots of video's in release notes?
Bij zichtbare wijzigingen wel. Een vernieuwd scherm begrijpen mensen sneller via een geannoteerde afbeelding, een GIF of een korte clip dan via tekst, en een verwijzing naar de documentatie voorkomt dat je een handleiding in de note schrijft. Kleine fixes hebben genoeg aan tekst.
Hoe schrijf je release notes voor een API-wijziging?
Begin met de codewijzigingen die integratoren moeten doorvoeren en hun uiterste datum, apart onder een eigen kop. Zet daaronder de breaking changes, nieuwe velden en verouderde endpoints, één per regel, en nummer daarna de upgradestappen. In voorbeeld 4 staat in de kopregel van Parcelo "Actie vereist vóór 15 januari 2027" nog vóór al het andere.
Hoe maak je release notes die mensen lezen?
Begin elke regel met het voordeel, bijvoorbeeld "Grote exports lopen niet meer vast op een time-out." Laat namen van interne componenten weg. Voorbeeld 1 opent met "Facturen zitten nu zelf achter hun betaling aan" en een samenvatting van het resultaat, gevolgd door de stappen om het in te stellen.
Gerelateerde voorbeelden
Voorbeelden van gebruikershandleidingen, Voorbeelden van kennisbanken, Voorbeelden van procesdocumentatie
