Release Notes Draft
{{ result.summary.primary }}
{{ result.summary.line }}
{{ badge.label }}
Name the product, release train, or feature set readers will recognize.
The version appears in headings, exports, and optional compare links.
Use the publication or rollout date for the release.
Choose who the finished notes should help first.
Pick where this draft will be published or reviewed.
Mark preview, stable, or yanked releases clearly before publishing.
State the main user-facing outcome before the section list.
Choose the shape of the changes you will paste or import.
{{ sourceHelp }}
{{ fileStatus || 'Drop TXT, MD, or LOG onto the textarea.' }}
Use one note per line. Leave blank only when no user action is needed.
Optional product or repository name for exports.
Optional previous tag for compare links.
Leave blank for portable release notes with no external link.
Optional; each line becomes a Known issues row.
Concise is safest for public notes; technical keeps scope prefixes and stronger change terms.
Turn off to remove common #123 and ABC-123 references from public copy.
Adds placeholder rows for sections that have no source entries.
{{ result.markdown }}
Section Release note Audience signal Release signal Source Copy
No release change rows generated.
{{ row.section }} {{ row.note }} {{ row.audience }} {{ row.signal }} {{ row.source }}
Gate Status Evidence Action Copy
{{ row.gate }} {{ row.status }} {{ row.evidence }} {{ row.action }}
Tags: Devtools, Productivity
Changelog Generator Draft a release changelog from notes, Markdown sections, or Conventional Commit subjects with category grouping, SemVer review, and copy-ready Markdown.
Regex Sample Matches Checker Test a JavaScript regex against examples that should pass or fail, with whole-line matching, flag checks, match spans, and timeout guards.
SemVer Bump Required Checker Check release notes and commit subjects for the required SemVer bump, compare a planned version, and review breaking, feature, fix, and neutral signals.
Meeting Minutes Generator Turn rough meeting notes into structured minutes with attendance, decisions, actions, review checks, and copyable Markdown for circulation.
Customize
Advanced
:

A release note is the handoff between changed software and the people who must decide what to do with it. A version number says which build, tag, or rollout is being discussed, but the note explains the practical change: what is new, what is fixed, what requires action, what is risky, and what is still known to be wrong.

Commit logs and pull request titles rarely make good release notes by themselves. They are written for development traceability, so they often include internal shorthand, partial fixes, merge noise, ticket IDs, and details that matter to maintainers more than users. Release communication turns those raw change lines into grouped, reader-facing statements.

Concept Why readers care Common mistake
Version Identifies the exact release readers should install, deploy, or compare. Publishing notes that do not match the shipped tag, package, or rollout label.
Release date Tells support, operations, and customers when the release became relevant. Using ambiguous regional dates in notes read by distributed teams.
Breaking change Warns that users, integrations, permissions, or configuration may need to change. Hiding migration work inside a general feature or improvement bullet.
Known issue Sets expectations before rollout and gives support teams a shared answer. Leaving the issue in private notes when readers need a visible workaround or limit.
Yanked release Signals that the release should no longer be used. Withdrawing a release without replacement, rollback, or impact guidance.

Audience changes the wording without changing the facts. Customer notes should put user-facing outcomes and plain warnings first. Developer notes can keep more API, scope, and compatibility language. Internal handoffs often need owner review, rollout risk, and support impact. A useful note lets the intended reader find the next decision without reading a full engineering history.

Change lines grouped into release-note sections, reader notes, audit trail, and publish check
  • Group related changes so readers can scan what is new, fixed, risky, or removed.
  • Separate user impact from internal cause; visible behavior and required action belong first.
  • Call out breaking, security, upgrade, deprecated, removed, known issue, and yanked-release signals plainly.
  • Keep version labels, dates, and compare links traceable because support teams often rely on them later.

A generated release note can classify and organize text, but it cannot prove that a change shipped, that a rollback is complete, or that a disclosure has been approved. Publication still needs a release owner or reviewer who knows the final state of the software.

How to Use This Tool:

Start with the release identity, then choose the input format that matches the change text you already have.

  1. Enter Release title, Version, and Release date. Use YYYY-MM-DD for the date so the Readiness Review does not flag an ambiguous release date.
  2. Choose Audience, Publication format, and Release status. Customer, developer, and internal notes keep the same facts but change the framing and review cues.
  3. Write a short Release summary that states the main outcome before the section list. If it is blank, the warning block asks for one.
  4. Set Change source format to the shape of the pasted text: categorized prefixes or Markdown headings, Conventional Commit lines, GitHub PR rows, or plain release bullets.
  5. Paste one change per line in Release changes, drop text onto the field, or browse for a TXT, Markdown, or LOG file under 512 KB. Use Sample to inspect a valid pattern and Normalize lines to trim uneven input.
  6. Add Upgrade or compatibility notes and Known issues when users must migrate, request a permission, delay rollout, check compatibility, or watch a limitation.
  7. Open Advanced for project name, previous version, repository URL, voice, issue-reference handling, and empty optional sections. Add the repository and previous version when a compare link should appear.
  8. Review Release Draft, Change Ledger, Readiness Review, and Review before publishing warnings. Fix ignored rows, duplicate collapse, blank version/date fields, missing summary text, yanked-release blockers, and compare-link gaps before sharing the draft.

Interpreting Results:

The summary reports how many release rows were parsed, how many sections are non-empty, which publication format and audience are selected, and whether major or review signals exist. Row count is not a quality score. It only shows how much text became visible release-note content.

Release Draft is the Markdown starting point. Read it as an announcement, not just as parsed text. A row can be placed in the correct section and still need clearer wording for customers, integrators, or support teams.

  • Change Ledger shows each note with its section, audience signal, release signal, and input cue. Use it to catch rows that landed in the wrong category or still sound like internal commit text.
  • Readiness Review labels gates as Ready, Review, or Blocker. A blocker should stop publication until the release owner fixes the missing or risky item.
  • Review before publishing warnings point to parser issues, blank fields, invalid dates, duplicate rows, missing summaries, or yanked-release guidance gaps.
  • JSON is useful when another workflow needs the generated summary, Markdown, ledger rows, review rows, warnings, and stats together.

Technical Details:

Release-note generation is a rule-based text transformation. The strongest input carries an explicit release signal: a section heading, known category prefix, Conventional Commit type, breaking-change marker, PR number, upgrade note, or known-issue note. Plain prose is weaker because it can be included but cannot reliably express whether the item is a fix, feature, security note, or compatibility warning.

The classification work has two parts. First, each change line is mapped to a release section such as Breaking Changes, Highlights, What is New, Improvements, Fixes, Security, Upgrade Notes, Known Issues, Deprecated, Removed, Documentation, or Other Notes. Second, the generated review data adds audience signal, release signal, parser warnings, duplicate collapse, status gates, and optional compare-link evidence.

Transformation Core:

Input path Primary cue Transformation behavior Warning or review point
Category prefixes or Markdown sections Prefixes such as added:, fixed:, security:, upgrade:, or matching Markdown headings. Recognized cues map to release-note sections; unprefixed lines under a recognized heading inherit that section. Unrecognized headings are skipped, and uncategorized lines fall back to Improvements with a warning.
Conventional commits or PR titles type(scope): summary, optional !, or BREAKING CHANGE: footer. feat becomes What is New, fix becomes Fixes, breaking markers become Breaking Changes, and other known types map by alias. Lines that do not match the commit pattern are ignored and counted in parser warnings.
GitHub PR list Rows beginning with a PR number, optionally followed by a Conventional Commit-style title and author handle. The PR number is retained as an input cue, and the title is classified by commit rules when possible. Rows without the expected PR-number shape are ignored; non-conventional PR titles fall back to Improvements.
Plain release bullets One plain change per line. Each line becomes a Highlights row because no stronger section signal is available. Breaking, security, upgrade, deprecated, removed, and known-issue text should be moved into clearer categories before publication.
Supplemental notes Upgrade or compatibility notes and known issues entered separately. Each line becomes an Upgrade Notes or Known Issues row and joins the generated draft and ledger. These rows should match the selected release status and audience because they often drive rollout decisions.

Duplicate collapse compares the final section and note text case-insensitively. If two rows say the same thing in the same section, one is kept and the duplicate count appears in warnings and the readiness review. When issue and PR references are not kept, common references such as #482 or ABC-123 are removed from note text so public copy does not expose tracking IDs unnecessarily.

Rule Core:

Gate Ready condition When the gate needs review
Version label A public version is present and matches the release artifact or tag. Add the release version before publishing, or confirm that the note is not tied to a versioned artifact.
SemVer shape The version looks like MAJOR.MINOR.PATCH, with optional prerelease or build metadata. A syntax match does not prove Semantic Versioning discipline; confirm compatibility promises separately.
Release date The date uses YYYY-MM-DD. Replace ambiguous regional dates before external announcements or handoffs.
Change coverage At least one change row is generated and visible in the draft and ledger. Paste notable changes or switch to the input format that matches the pasted text.
Breaking, upgrade, security, and known issue signals Risk-bearing rows are visible and action wording is clear. Confirm migration, disclosure, known-limit, owner-approval, or rollback wording before publishing.
Yanked release status Withdrawn releases include replacement, rollback, or impact guidance. The readiness review marks yanked status as a blocker until that guidance is present.
Compare link Repository URL, previous version, and current version form a link that reviewers can verify. Add the missing fields or omit the link and rely on the written release body.

A typical breaking commit path is feat(api)!: require export.read scope to Breaking Changes, a Major release signal, and a readiness row asking reviewers to confirm migration wording. Adding a separate upgrade note makes the required action visible instead of leaving it inside the change title.

Privacy and Accuracy Notes:

Release text can include unreleased features, customer names, ticket IDs, vulnerability details, rollback plans, or internal owner notes. TXT, Markdown, and LOG files are read locally in the browser workflow and files over 512 KB are rejected, but the generated draft and exports still contain whatever sensitive text was pasted or loaded.

  • Verify that each change actually shipped and was not reverted, delayed, or hidden behind a feature flag.
  • Confirm the version label, release date, release status, and compare link against the final release artifact.
  • Have security, breaking-change, known-issue, and yanked-release language reviewed by the responsible owner.
  • Turn off issue and PR references when public notes should not expose ticket IDs or internal tracking patterns.

Advanced Tips:

  • Use categorized input when you already know the release sections. It gives better control over security, upgrade, deprecated, removed, and known-issue rows than plain bullet mode.
  • Use Conventional Commit mode only for lines that follow type(scope): summary or BREAKING CHANGE:. Non-matching lines are ignored and reported in parser warnings.
  • Switch Voice to a more technical setting when scope names help developer readers, but keep customer notes outcome-focused.
  • Turn off Keep issue and PR references when public notes should not expose ticket IDs such as #482 or ABC-123.
  • Use Include empty optional sections for internal review drafts when reviewers need to confirm that a section is intentionally empty before publication.
  • Select Yanked release only when replacement, rollback, or impact wording is ready; otherwise the readiness review correctly treats the release status as a blocker.

Worked Examples:

Customer Release From Categorized Bullets

A list with added: Scheduled CSV exports can now be shared with finance reviewers and fixed: Billing status badge no longer stays stale after plan changes produces What is New and Fixes sections in Release Draft. Change Ledger keeps the section and audience signal so a reviewer can check whether the wording is safe for customers.

Breaking API Change

A Conventional Commit line such as feat(api)!: require export.read scope for scheduled export endpoints becomes Breaking Changes with a Major release signal. Add the migration action in Upgrade or compatibility notes; otherwise the readiness review can still ask for clearer upgrade guidance.

Ignored PR Row

In GitHub PR list mode, #482 feat(exports): add scheduled CSV export sharing @mira is parsed with the PR number as an input cue. A row that omits the PR number is counted in parser warnings, so rewrite the row or switch to a better Change source format.

FAQ:

Can I paste a full commit log?

Use a full log only when the lines match the selected format. Conventional Commit mode ignores non-matching lines, while categorized mode works best with recognized prefixes or Markdown headings.

Why did a change become an Improvement?

Categorized input sends unprefixed lines to Improvements when no recognized heading is active. Add a prefix such as added:, fixed:, security:, upgrade:, deprecated:, or removed: when the section matters.

Does the SemVer check prove my version is correct?

No. The readiness review checks whether the label looks like MAJOR.MINOR.PATCH. It cannot prove that the release actually follows the compatibility promises behind major, minor, and patch changes.

What happens to duplicate notes?

Duplicate rows with the same section and note text are collapsed case-insensitively. The warning block and Readiness Review report the duplicate count so you can confirm whether repeated entries were intentional.

Why did my file not load?

The file import is for TXT, Markdown, or LOG text under 512 KB. A larger file shows Use a TXT, MD, or LOG file under 512 KB., and a browser read failure shows The file could not be read in this browser.

Which output should I check before publishing?

Read Release Draft for final wording, Change Ledger for section and signal accuracy, and Readiness Review for missing version, date, summary, parser, compare-link, yanked-release, and rollout checks.

Glossary:

Release note
A reader-facing explanation of notable changes in a specific software release.
Changelog
A chronological record of notable changes across versions, often broader and more durable than one release announcement.
Conventional Commit
A commit-message convention using a type, optional scope, description, and breaking-change markers.
SemVer
Semantic Versioning, where major, minor, and patch numbers communicate compatibility meaning when the project follows the standard.
Breaking change
A change that can require users or integrations to adjust usage, configuration, permissions, or compatibility assumptions.
Yanked release
A release that should no longer be used and needs replacement, rollback, or impact guidance.
Change Ledger
The result table that lists each generated note with its section, audience signal, release signal, and input cue.
Readiness Review
The result table that checks publication gates such as version, date, parsed changes, summary, warnings, risk rows, status, and compare link.

References: