Příklady release notes pro každý druh změny

Nejlepší příklady release notes jsou krátké, jmenují, koho se změna týká, a říkají, co dělat dál. Níže je jeden příklad pro každý druh změny, který budete vydávat, s důvodem, proč funguje, takže můžete okopírovat tvar a dosadit vlastní fakta.

Každý příklad je vymyšlený, pro fiktivní fakturační aplikaci Tidepool.

Co mají společného dobré příklady release notes?

Říkají uživatelům, co se změnilo a co s tím případně mají udělat, jejich vlastními slovy. Každý druh změny má jiný úkol, takže tvar se mezi nimi mění.

Jak vypadá dobrá poznámka o nové funkci?

Dobrá poznámka o funkci začíná tím, co čtenář nyní může dělat, a jmenuje tarify nebo role, které ji dostanou. Implementaci vynechává.

Posílejte faktury v jazyce zákazníka. U každého zákazníka teď můžete zvolit jazyk a jeho faktury, upomínky i platební stránka se jím řídí. Francouzština, němčina, španělština a portugalština jsou dostupné ve všech tarifech. Nastavíte to na stránce zákazníka v části Předvolby fakturace.

Nadpis je věta, kterou by čtenář řekl nahlas, a text dává rozsah a umístění. Čtenář, který přeletí jen tučný řádek, stále ví, co se vydalo. Širší metoda je v článku jak psát release notes.

Jak vypadá dobrá poznámka o vylepšení?

Poznámka o vylepšení popisuje změnu, kterou čtenář pocítí, a pokud existuje, uvádí naměřené číslo. Bez čísla řekněte, co už čtenář dělat nemusí.

Seznam faktur se načítá zhruba třikrát rychleji. Účty s více než 5 000 fakturami čekaly na seznam asi devět sekund. Nyní se otevře zhruba za tři. Není potřeba nic dělat.

«Vylepšení výkonu» čtenáři neříká nic, zatímco devět sekund proti třem je tvrzení, které si může v pondělí ráno ověřit. Závěrečné «Není potřeba nic dělat» odpovídá na otázku, kterou má každý čtenář.

Jak vypadá dobrá poznámka o opravě chyby?

Poznámka o opravě popisuje příznak, který uživatel viděl, ne příčinu v kódu, a říká, zda musí něco zopakovat. Opravy, kterých si nikdo nevšiml, mohou jít do seznamu dole.

Opraveno: upomínky se v den splatnosti odesílaly dvakrát. Někteří zákazníci dostali dvě stejné upomínky, pokud byla faktura splatná poslední den v měsíci. Je to opraveno. Už odeslané upomínky se to netýká a nikdo nemusí nic odesílat znovu.

Nadpis začíná slovem «Opraveno», aby ho šlo na první pohled roztřídit, a skutečná podmínka (poslední den v měsíci) následuje hned potom.

Jak napsat release notes k zásadní změně?

Poznámka o zásadní změně začíná datem a dotčenou skupinou a hned v témže záznamu uvádí migraci. V release notes jde na první místo, protože je to jediný záznam, který čtenář nesmí minout.

Podpisy webhooků budou povinné od 1. prosince 2026. Od tohoto data Tidepool přestane posílat nepodepsané payloady webhooků. Týká se to každého, kdo přijímá webhooky bez kontroly hlavičky Tidepool-Signature. Pro migraci ověřujte hlavičku pomocí tajného klíče v Nastavení, Vývojáři. Pokud podpisy už ověřujete, nemusíte nic dělat.

Datum je v nadpisu, takže přežije přelétnutí. Dotčená skupina je pojmenována podle toho, co dělá, a poslední věta uvolní lidi, kteří jsou už v pořádku, což snižuje zátěž podpory. Průvodce breaking changes popisuje, jak rozhodnout, zda se změna počítá.

Jak vypadá poznámka o bezpečnostní opravě?

Bezpečnostní poznámka říká, co bylo odhaleno, zda to někdo zneužil, koho se to týká a co musí udělat. Držte ji věcnou a klidnou.

Bezpečnost: odkazy pro obnovu hesla šlo použít opakovaně. Mezi 3. a 17. zářím 2026 zůstal odkaz pro obnovu hesla platný i po prvním použití. Nenašli jsme žádné známky zneužití. Je to opraveno a všechny dosud nepoužité odkazy byly zneplatněny. Pokud jste si v tomto období vyžádali obnovu, požádejte o nový odkaz.

Přesné období umožní čtenáři posoudit vlastní zasažení a věta o zneužití odpovídá na první otázku, kterou si každý klade. «Možný problém» vyznívá jako zatajování, proto uveďte, co víte.

Jak napsat oznámení o deprekaci?

Oznámení o deprekaci pojmenuje, co se odstraňuje, uvede pevné datum konce a odkáže na náhradu.

Endpoint faktur ve verzi v1 je deprekovaný a končí 1. března 2027. GET /v1/invoices funguje do 1. března 2027, poté vrací 410 Gone. Použijte GET /v2/invoices, který vrací stejná pole plus currency. Odpovědi z v1 nyní obsahují hlavičku Sunset s datem konce. Průvodce migrací vedle sebe najdete v dokumentaci.

Název endpointu je v nadpisu, protože dotčení lidé ho hledají, a náhrada stojí hned vedle odstranění. Hlavička Sunset říká vývojářům, která volání ještě používají starou verzi. Podrobnější výklad je v článku deprekace API.

Jak vypadá poznámka v obchodě s aplikacemi?

Poznámka v obchodě s aplikacemi jsou dvě nebo tři prosté věty, protože většina lidí čte jen první řádek. Začněte změnou, které si uživatel všimne.

Naskenujte papírovou účtenku a Tidepool doplní částku, datum a dodavatele. Tmavý režim nyní sleduje nastavení telefonu. Opravili jsme také pád při otevření faktury z notifikace.

Nejužitečnější změna je první a oprava jmenuje situaci, která padala. Není tam číslo verze ani «opravy chyb a vylepšení». Release notes pro mobilní aplikace popisují pravidla jednotlivých obchodů.

Co má obsahovat interní poznámka k vydání?

Interní poznámka je verze pro podporu a prodej. Přidává to, co veřejná poznámka vynechává: co říkat a co neslibovat.

Vícejazyčné faktury se dnes vydaly (všechny tarify). Podpora: zákazníci nastavují jazyk v Předvolbách fakturace a stávající faktury si ponechají původní jazyk. Italština zatím není dostupná. Prodej: je to otevřené všem tarifům, takže ji neprezentujte jako upgrade.

Každé skupině patří vlastní označený řádek a poznámka vytyčí hranici («Italština zatím není dostupná») dřív, než se zákazník zeptá. Článek o interních release notes popisuje formát a kanály.

Jak vypadá špatná poznámka k vydání po přepsání?

Špatná poznámka vypisuje, co udělal tým, místo toho, co čtenář dostává. Opravíte ji přesunutím výsledku dopředu a vymazáním interní slovní zásoby.

Před:

v3.8.1 Refaktorován plánovač upomínek. Opraven race condition v ReminderJob. Aktualizován bull na 4.12. Různá vylepšení.

Po:

Upomínky se už neodesílají dvakrát. Zákazníci s fakturou splatnou poslední den v měsíci mohli dostat dvě upomínky. To je opraveno a už odeslané upomínky není třeba posílat znovu. Není potřeba nic dělat.

Také v 3.8.1: bull aktualizován na 4.12.

Aktualizace závislosti spadla do řádku v patičce a race condition se změnil v příznak, který by zákazník poznal.

Jak udržet release notes konzistentní napříč vydáními?

Každý záznam navrhněte, když se změna sloučí, a nechte ho před vydáním schválit člověkem.

Changeloop funguje tímto způsobem: z každého sloučeného pull requestu navrhne záznam pomocí AI a drží ho, dokud ho člověk neschválí. Schvalování je místo, kde redaktor uplatní výše uvedená pravidla. Pokud chcete nejdřív ustálit formát, začněte od šablony release notes a podívejte se na příklady changelogu, jak vypadají hotové stránky.

FAQ

Co jsou nové release notes? Nové release notes jsou zpráva zveřejněná s nejnovějším vydáním produktu, která popisuje, co se změnilo a co mají uživatelé udělat. Zahrnují funkce, vylepšení, opravy a zásadní změny.

Jaký je rozdíl mezi release note a changelogem? Changelog uchovává všechno, pro každého, kdo chce celou historii. Release note z něj vybírá: jedno vydání, psané pro čtenáře, kteří se rozhodují, zda je pro ně důležité. Podrobnější srovnání je v článku changelog vs release notes.

Co znamená release notes? Release notes říkají uživatelům, co se ve vydání změnilo. Výraz zahrnuje cokoli, co vysvětluje, co se vydalo, od textu «Co je nového» v obchodě s aplikacemi po stránku na webu firmy.

Jak dlouhý má být každý záznam v release notes? Dvě až čtyři věty stačí pro většinu záznamů: výsledek, koho se týká a co dělat. Zásadní změna nebo bezpečnostní oprava může být delší, protože potřebuje datum nebo migraci.

Technická tvrzení v tomto článku nikdo nezávisle neověřil. Pokud tu něco nesedí, dej nám vědět a opravíme to.

Související na changeloop: Šablona poznámek k vydání, Příklady changelogu