{{ summaryTitle }}{{ summaryValue }}{{ summaryLine }}

{{ sourceModeHelp }}
{{ fileStatus || 'Drop one TXT, MD, or LOG file; files stay in this browser.' }}
This becomes the release heading; a leading v is removed from display.
Use YYYY-MM-DD so the heading stays unambiguous.
Choose the artifact you intend to paste or download.
This is a review hint; it never changes the version field automatically.
Blank keeps the neutral # Changelog heading.
The default adds no repository-specific output.
Off omits categories that have no accepted entries.
{{ params.include_empty_sections ? 'Include' : 'Omit' }}
Off leaves the full file focused on the current release.
{{ params.include_unreleased ? 'Include' : 'Omit' }}
Off preserves repeated source lines for review.
{{ params.collapse_duplicates ? 'Collapse' : 'Keep' }}
Use only for a release withdrawn after publication.
{{ params.yanked_release ? 'Yanked' : 'Normal' }} 
{{ values.markdown }}
#CategoryChangeSource cueSemVer signalCopy
No accepted changes yet.
{{ row.index }}{{ row.category }}{{ row.change }}{{ row.source }}{{ bumpLabel(row.semver) }}
CheckStatusDetailNext actionCopy
{{ row.check }}{{ row.status }}{{ row.detail }}{{ row.action }}
Release Notes Generator Turn commits, pull requests, or release bullets into audience-ready Markdown with grouped changes, parser warnings, and publication checks.
Conventional Commit Messages Checker Check Conventional Commit headers or full messages against repository rules and see each valid message’s release impact before publishing.
SemVer Bump Required Checker Check release notes and commit subjects for the required SemVer bump, then verify whether a planned version covers the strongest change signal.
Acceptance Criteria Generator Draft testable acceptance criteria from behaviors and edge cases, then check Gherkin or QA handoff wording for missing coverage and vague terms.

A release can be technically complete and still leave its users guessing. Commit subjects record development steps, while a changelog should explain the notable effect of a release on people who install, operate, integrate, or support the software. That distinction matters when a repository contains internal refactors, partial work, merges, and maintenance commits that do not belong in public release notes.

Useful changelogs make changes easy to find across versions. Stable headings separate new functionality from changed behavior, deprecations, removals, fixes, and security work. An Unreleased section can collect upcoming changes, and dated version headings create a history that remains readable outside a hosting platform.

Release evidence What it contributes What still needs judgment
Commit history Traceable engineering changes and scopes Which commits are notable to users
Issue or release notes Impact, migration context, and public wording Consistent categories and version placement
Semantic version A compatibility signal in major, minor, and patch form The actual behavior change and any required action

Semantic Versioning describes changes to a declared public API. A major increment signals an incompatible change, a minor increment a backward-compatible addition or deprecation, and a patch increment a backward-compatible bug fix. A changelog can support that decision, but category names alone cannot prove compatibility. A line placed under Added may still hide a breaking migration, and a Security entry may need coordinated disclosure rather than a detailed public explanation.

Generated structure is therefore a drafting aid, not a release approval. Before publishing, compare the accepted entries with the intended release range, confirm that important removals and migration steps are present, and check that the version communicates the real public impact.

How to Use This Tool:

Choose the source shape that already matches your notes, then review how every accepted line was categorized.

  1. Enter Version and Release date. Use a full semantic version or Unreleased; published versions should use a calendar-valid YYYY-MM-DD date.
  2. Choose Source format, or leave Auto detect selected. Paste categorized lines, recognized Markdown sections, or Conventional Commit subjects into Release changes.
  3. Set SemVer signal. The strict Conventional Commits policy recognizes breaking markers, feat, and fix; the release-note policy derives a signal from the final changelog categories.
  4. Choose a release entry or full changelog under Output scope. Add repository and previous-version details only when reference compare links are required.
  5. Read the Change ledger and Release audit before using the Markdown. Correct skipped lines, unexpected Changed entries, version or date warnings, and compare-link assumptions at the source.

Interpreting Results:

The recommended bump is the strongest signal found in the accepted rows. Major outranks minor, minor outranks patch, and patch outranks no bump. It is intentionally conservative evidence from text patterns, not an analysis of the public API.

  • Ready means at least one change was accepted and no drafting warning was produced.
  • Review means a usable draft exists with a condition such as a fallback Unreleased heading, non-ISO release date, parse note, missing repository context, or collapsed duplicate.
  • Needs work means no accepted change remains. Add or correct source lines before treating the Markdown as a release entry.

Technical Details:

Changelog generation is an ordered text transformation. Line endings and surrounding whitespace are normalized, the source mode selects a parser, accepted rows receive one of six fixed categories, and the final sections always follow Added, Changed, Deprecated, Removed, Fixed, then Security.

Transformation Core:

Source path Recognition rule Unrecognized content
Categorized entries Uses a recognized heading or prefix such as added:, fixed:, or security:; Conventional Commit syntax is also accepted. A plain line becomes Changed. Unsupported Markdown headings produce a parse note.
Markdown sections Accepts list content below recognized level 2 to level 6 category headings. Lines outside recognized sections and unsupported headings are skipped with counts.
Conventional Commits Reads type(scope): subject, an optional !, and standalone BREAKING CHANGE: lines. Nonmatching lines are ignored with a count. Unknown but syntactically valid types map to Changed.
Auto detect A recognized Markdown heading wins first. Otherwise, every nonempty line must be a recognized Conventional Commit type or breaking footer for that mode to be chosen. All other input uses categorized parsing.

Rule Core:

The category and policy together determine the displayed bump signal. These rules describe the draft model; the maintainer must still judge the actual public API change.

Evidence Release-note policy Strict Conventional Commits policy
Breaking footer, leading breaking text, or ! Major Major
Removed Major No bump unless the Conventional Commit carries a breaking marker
Added, Changed, or Deprecated Minor feat is Minor; other nonbreaking types are No bump
Fixed or Security Patch fix is Patch; other nonbreaking types are No bump

Optional duplicate collapse compares the final category and change text without case sensitivity. It removes later repeats only after parsing, so the same sentence in two different categories remains distinct. Empty categories are omitted unless requested, and an empty accepted set produces a no-notable-changes placeholder.

A release heading accepts Unreleased or full Semantic Versioning syntax, including prerelease and build metadata. Reference links require a repository URL and a published version. With a previous version they use a compare range; without one they point to the current release tag. The version text is normalized to a single leading v in generated link targets.

The source limit is 512 KiB. Input longer than the field limits, unsupported modes, and invalid policy choices block evaluation. Version and date concerns remain review warnings so an incomplete draft can still be inspected and corrected.

Privacy Notes:

Release text is parsed in the browser and no server-side processor receives it. That does not make sensitive details suitable for a public changelog: remove credentials, private issue context, exploit details under embargo, and internal host or customer names before publishing or sharing the output.

References: