JustHandled Labs
// developer release workflow

Changelog Generator

Turn the Git history you select into plain Markdown release notes: every commit accounted for, breaking markers preserved, and the next version suggested without pretending a commit label proves compatibility.

Three ways to define the release

Revision rangeUse a two-dot Git range such as v1.4.2..HEAD when the release boundary is known.
Recent commitsUse the last 10, 20, or another positive count for an untagged project or draft update.
Tag comparisonCompare the newest two tag references; with one tag, compare it to HEAD.
Safe defaultUse the nearest reachable tag to HEAD, or report a tagless fallback to the last 20 commits.

A release note that remains auditable

# Release Notes: v2.0.0

Suggested version: `v2.0.0`
Range: `v1.4.2..HEAD`
Commits analyzed: 3

## Summary

This release includes one feature, one fix, and one breaking change across 3 commits.

## Breaking Changes

- Removed the legacy configuration fallback. (`a1b2c3d`)

## Features

- Added project-level release-note generation. (`d4e5f6a`)

## Chores

- Updated the dependency lockfile. (`0b1c2d3`)

The helper removes recognized Conventional Commit prefixes, keeps the seven-character hash for traceability, and uses portable text headings rather than terminal-dependent emoji.

Tolerant parsing without silent omissions

Requirements and data boundary

The deterministic helper needs Git, Python 3.9 or newer, and local read access to the repository. It collects commit hashes, subjects, and bodies. It does not read file contents, diffs, authors, remotes, credentials, or environment variables.

It never fetches, pulls, pushes, tags, commits, creates a hosted release, or opens a network connection. Markdown is returned to the agent by default; a file is written only when an output path is explicitly requested.

What the version suggestion can and cannot establish

Version 1.3 follows the Conventional Commits mapping: a breaking marker suggests a major bump, a feature suggests a minor bump, and the remaining recognized changes suggest a patch. It preserves a leading v and has a documented fallback when no SemVer-like tag exists.

Maintainer review still matters. A commit can be mislabeled, an incompatible change can be undocumented, and a custom commit type can describe meaningful product work. Treat the version as a review prompt, not a release decision.

Questions

Which commit selections can Changelog Generator use?

It accepts an explicit Git revision range, the most recent N commits, the two newest tag references, or the nearest reachable tag to HEAD. With no tags, it falls back to the last 20 commits and reports the fallback.

How does it detect breaking changes?

It recognizes an exclamation point immediately before the Conventional Commit colon plus BREAKING CHANGE: and BREAKING-CHANGE: markers in the subject or body, case-insensitively.

What happens to malformed commit messages?

They remain visible under Chores instead of being discarded. A malformed commit can still appear under Breaking Changes when its subject or body contains a breaking marker.

Does it modify or publish the repository?

No. It reads local Git history only. It does not fetch, pull, push, tag, commit, create a release, read diffs or file contents, or open a network connection.

Is the suggested SemVer version authoritative?

No. The suggestion follows recognized commit markers and the nearest SemVer-like tag. It cannot prove API compatibility or correct a mislabeled commit, so a maintainer must review it.

What does the deterministic helper require?

It requires local Git, Python 3.9 or newer, and read access to the target repository. The helper uses only the Python standard library.

Turn the selected commits into release notes you can inspect.

Version 1.3 includes the deterministic helper, exact format guide, and 11 fixture-backed tests. Review the current version, permissions, and refund terms on Agensi before buying.

Get Changelog Generator on Agensi