Changelog Generator

Release work leaves behind a technical history and a reader-facing history. The technical history explains how code moved from one state to another. The reader-facing history explains what changed for people who install, operate, test, support, or depend on the software.

A useful changelog sits between raw engineering notes and a polished announcement. It should be specific enough for someone to decide whether an upgrade matters, but concise enough that security fixes, removals, deprecations, and compatibility changes are not buried under routine maintenance. Teams often use it during release review, customer support triage, dependency upgrades, incident follow-up, and migration planning.

Commit log

A chronological engineering trail. It is valuable for maintainers, but it can include noisy, internal, or partial changes.

Release notes

Reader-facing notes for a release. They may be short, but they should explain the notable user, operator, or integrator impact.

Changelog

A versioned history of release notes, normally ordered newest first and grouped by change type.

Migration notes

Extra instructions for upgrades that change behavior, remove support, or require configuration work.

Stable sections make the document easier to scan across releases. Additions answer what is new, fixes answer what was corrected, deprecations and removals warn about upgrade work, and security entries tell readers which releases deserve extra attention. Vague catch-all sections make review harder because readers must infer whether a change affects compatibility, risk, or only internal housekeeping.

Semantic Versioning and changelog writing answer related but separate questions. A version number gives a compatibility signal: patch for backward-compatible fixes, minor for backward-compatible additions or deprecations, and major for incompatible public API changes. A changelog explains human impact, including security urgency, configuration work, support notes, or migration steps that a number alone cannot carry.

Automation earns its place when it turns messy release text into a structured draft for review. Prefixes, section headings, and Conventional Commit subjects can sort entries consistently, but they cannot know whether a change is public, whether a deprecation is complete enough, or whether a security note should be intentionally vague. The final changelog still needs a maintainer to check impact, wording, and release policy.

The common mistake is treating generated release notes as proof that the release is ready. A clean draft means the notes have been organized. It does not prove that every important change was captured, that the compare range is correct, or that the version number matches the real compatibility change.

How to Use This Tool:

Start with the release identity, then choose the input shape that matches the notes you already have.

1. Enter Version as a release number such as 2.4.0, a tag-style value such as v2.4.0, or Unreleased when the notes are not published yet. The generated heading uses this value.
2. Set Release date for a published release. Use a full ISO date such as 2026-05-31; the Release Audit will ask for review when a published heading has a blank or non-ISO date.
3. Choose Source format. Use Categorized entries for lines like fixed: repair export spacing, Keep a Changelog Markdown sections for pasted ### Added style blocks, or Conventional commits for subjects like feat(api): add filters.
4. If Conventional commits is selected, choose the SemVer signal policy. Strict mode follows feat, fix, !, and BREAKING CHANGE:; release-note category mode also lets Removed, Deprecated, Security, and Changed entries influence the signal.
5. Pick Output scope. Release entry only is ready to paste into an existing changelog; Full CHANGELOG.md adds the standard heading and can include an empty Unreleased section.
6. Paste the release changes, drop a TXT, MD, or LOG-style file, or load the sample. Use Normalize lines if copied text has trailing spaces or mixed line endings. Files over 512 KB are rejected, so paste a smaller excerpt when needed.
7. Review Changelog Markdown, Change Ledger, and Release Audit before copying, downloading Markdown, exporting tables, or reusing JSON. Warnings above the results point to uncategorized lines, skipped headings, duplicate handling, missing links, or date/version problems.

Use the Advanced controls only when they change the published draft. A project name is useful for full-file output, reference compare links need a repository URL and previous version, duplicate collapsing should be turned on only when repeated entries are accidental, and Yanked release should be reserved for a release that was withdrawn after publication.

Interpreting Results:

Read the summary as a release-note health check, not as a publishing decision. The change count shows how much input was accepted, the section count shows how widely the notes were distributed, and the SemVer signal reports the strongest parsed compatibility hint under the selected policy.

A clean Markdown draft can still be incomplete. The Change Ledger and Release Audit catch misplaced categories, skipped lines, missing dates, duplicate cleanup, and version-link assumptions before the text is copied into a project repository.

The strongest false-confidence risk is a structurally tidy changelog with the wrong public impact. Compare the Markdown with the Change Ledger, then verify the Release Audit before copying the draft or reusing the JSON output.

Technical Details:

Changelog generation is a deterministic text-classification task. Each accepted line needs a section, a cleaned reader-facing sentence, a traceable cue from the input, and a release signal that can be reviewed before publication. The same pasted notes should produce the same grouping until the text, source format, or SemVer policy changes.

The governing logic is rule-based rather than formula-based. Version review depends on categories, Conventional Commit markers, breaking-change signals, date validity, and optional compare-link context. Every ledger row should explain why a line landed in a section and why it raised, or did not raise, the SemVer signal.

Transformation Core:

Input lines move through one of three parsing paths. Empty lines are ignored, simple Markdown bullets are stripped where they are part of the source format, and recognized category language is normalized to the Keep a Changelog section set.

Category Map:

Keep a Changelog uses a small section vocabulary, so similar wording is folded into stable headings. The map is intentionally conservative: unclear lines in categorized mode become Changed with a warning rather than being silently discarded.

Rule Core:

The version signal is a review hint, not a release command. When multiple entries are present, the strongest signal wins in this order: Major, Minor, Patch, then No bump.

Validation Boundaries:

Release metadata is checked separately from text classification because a well-grouped changelog can still have an unsafe heading or broken compare context.

Release headings accept a supplied version or Unreleased. Published versions use a date in the heading, yanked releases add [YANKED], and full changelog output can add the standard top heading plus an optional empty Unreleased section.

Reference compare links are appended only when link output is requested and the needed repository context is present. A previous version creates a comparison range; a blank previous version turns the current version into a release-tag link.

Privacy Notes:

Release notes often contain unreleased product details, security context, customer-impact wording, or internal issue language. Treat pasted text as draft release material until it has been reviewed for public wording and disclosure timing.

• Changelog Markdown, the Change Ledger, the Release Audit, and JSON are generated in the browser from the text you enter.
• Dropped TXT, MD, or LOG-style files are read into the release-change field so you can inspect the content before using the output.
• Copied or downloaded output should be reviewed before it is committed, attached to a release, or shared with customers.

Worked Examples:

Category-prefixed maintenance release. Input such as fixed: Preserve blank lines in copied release notes and security: Redact token values in audit downloads should produce Fixed and Security sections. The summary should show a Patch SemVer signal, and the Release Audit should still be checked for date and version readiness.

Conventional Commit feature release. With feat(exports): add Markdown download, fix(parser): keep scoped commits, and docs: refresh examples, Conventional Commit strict mode should classify the feature as Added, the fix as Fixed, and the docs entry as Changed with no bump effect. The strongest signal should be Minor.

Markdown section import. A pasted block headed ### Deprecated with bullets underneath should keep those bullets in the Deprecated section until a new recognized heading appears. A later ### Internal heading is not a supported changelog section, so lines beneath it need review or a supported heading.

Breaking release review. A subject such as perf!: remove legacy cache should raise a Major signal even though perf alone has no strict SemVer bump. The generated Markdown may look ready, but the release still needs migration wording and a deliberate version decision.

Troubleshooting an unclear paste. A line like Updated export buttons has no category prefix and no commit shape. In categorized mode it is accepted as Changed with a warning. Rewriting it as changed: Update export button labels removes the ambiguity and makes the Change Ledger easier to review.

FAQ:

Glossary:

Changelog

A versioned record of notable changes intended for people who use, operate, or maintain the software.

Keep a Changelog

A common changelog format with sections such as Added, Changed, Deprecated, Removed, Fixed, and Security.

Conventional Commit

A commit subject with a type, optional scope, optional breaking marker, and description.

SemVer signal

A Major, Minor, Patch, or No bump hint inferred from parsed release evidence.

Unreleased

A changelog section for changes that have been recorded but not assigned to a published version.

Yanked release

A release that was published and later withdrawn, marked in the heading with [YANKED].

References:

• Keep a Changelog 1.1.0, Keep a Changelog.
• Semantic Versioning 2.0.0, Semantic Versioning.
• Conventional Commits 1.0.0, Conventional Commits.
• How to view Git commit history, Simplified Guide.
• How to create a Git release tag, Simplified Guide.