Classify the config rename as breaking
“timeout becomes requestTimeout and the old one no longer works” is incompatible. It moves into the breaking section with a migration note to rename and restart.
Turn commits, change lists, or release drafts into release notes grouped into added, fixed, changed, and breaking changes. No invented version numbers, dates, or impact scope; breaking changes get their own section with a migration note, and gaps are marked as to be confirmed.
We classify each entry, put breaking changes in their own section with a migration note, and flag missing versions and dates.
SAMPLE OUTPUT
This is the complete output for the source text in the demo above: a completeness score, itemised classification notes, what was marked as to be confirmed and why, and the structured changelog. It is a demonstration, not a customer case.
“timeout becomes requestTimeout and the old one no longer works” is incompatible. It moves into the breaking section with a migration note to rename and restart.
“Export is much faster” has no measurement behind it, so it is withheld from the change description and listed as needing data.
Export, login, and interface were packed into a single line. They become separate entries so the one that affects upgrading cannot vanish.
# Changelog (draft) Version: to be confirmed (no version number or release date in the source) ## Added - To confirm: no entry can be clearly classified as added (the source says “the interface was adjusted a bit” without saying how) ## Fixed - Fixed a login-related issue: the source gives no symptom or trigger condition — to confirm ## Changed - Export behaviour adjusted: the source claims “much faster” with no measurements; that claim is withheld pending data - Interface adjustments: the source does not say where or what changed — to confirm ## Breaking changes - The config option `timeout` is renamed to `requestTimeout`; the old option no longer takes effect. - Migration: rename `timeout` to `requestTimeout` in your configuration and restart the service. - To confirm: whether the old option fails silently or errors, and whether there is a compatibility window ## Items to verify - Version number and release date - The actual symptom and scope of the login issue - Whether any measurement supports “export is faster” - How the old config fails and whether a compatibility window exists
WHAT DRAFTING DOES
The same change is a new capability or a behaviour change depending on what the user sees, and that decides whether it is added or changed.
Incompatible changes never hide among ordinary changes. They are labelled separately with what the user must do.
Version numbers and release dates come from your release process. When absent, they read as to be confirmed rather than a plausible guess.
WHY IT IS WORTH DOING
People read release notes before upgrading to answer one question: do I have to change my code. A hidden incompatibility will be hit.
A casually written version does not match what is deployed, and everyone debugging follows the wrong path.
Compress three changes into one line and the one that actually affects the upgrade is the one that disappears.
Note: common practice for changelogs is a fixed set of categories organised by version, with incompatible changes and migration steps marked prominently. Projects differ in versioning scheme and category names. This site drafts documents only; it reads no repository or diff and does not judge whether a release is safe.
DRAFTING DEMO
This update optimises the export feature, export is much faster now. Also fixed a login bug, and renamed the config option timeout to requestTimeout, the old config no longer works. The interface was adjusted a bit too.
# Changelog (draft) Version: to be confirmed (no version number or release date in the source) ## Added - To confirm: no entry can be clearly classified as added (the source says “the interface was adjusted a bit” without saying how) ## Fixed - Fixed a login-related issue: the source gives no symptom or trigger condition — to confirm ## Changed - Export behaviour adjusted: the source claims “much faster” with no measurements; that claim is withheld pending data - Interface adjustments: the source does not say where or what changed — to confirm ## Breaking changes - The config option `timeout` is renamed to `requestTimeout`; the old option no longer takes effect. - Migration: rename `timeout` to `requestTimeout` in your configuration and restart the service. - To confirm: whether the old option fails silently or errors, and whether there is a compatibility window ## Items to verify - Version number and release date - The actual symptom and scope of the login issue - Whether any measurement supports “export is faster” - How the old config fails and whether a compatibility window exists
Demo sample: unsupported speed claims are demoted to items to confirm, and a config rename is classified as breaking with a migration note attached. Paste your list to get your version (sign-in required; one credit per run).
WHY YOU CAN TRUST IT
Incompatible changes are never mixed into ordinary changes; they are labelled separately with the action the user must take.
When the source has no migration step, we say it is missing and list it for verification instead of inventing a plausible procedure.
Version numbers, release dates, and build numbers come from your release process; missing ones read as to be confirmed.
Submitted text is used for this single AI request and is not intentionally persisted. See the Privacy Policy.
FAQ
We flag anything suspicious, but the call is yours. Clearly incompatible changes — renamed config options, changed API parameters — are classified as breaking; borderline ones are marked and listed for verification.
We state under that entry that the migration note is missing and list it for verification, rather than inventing a procedure that looks reasonable.
No. Those come from your release process. When the source lacks them, the entry reads as to be confirmed so it cannot contradict what is actually deployed.
One credit per run, usually done in seconds, returning the changelog, revision notes, and items to verify.
No. Credits never expire — whatever you do not use carries over to the next cycle instead of resetting.
Not yet. Each run processes one document and consumes one credit; there is no bulk upload or API today. Email us with your use case and we will assess it.
Not intentionally. Text is used for this single AI request only. See the Privacy Policy.
Commit summaries, pre-release change roundups, bug-fix lists from beta feedback, draft release notes for open-source projects — any change description that needs to become a real changelog.
SIMPLE PRICING
For an occasional publishing cadence, with a focused monthly credit allocation.
For frequent publishers who iterate on content continuously.
Our largest monthly credit allocation, for the heaviest continuous usage.
Credits never expire: unused credits carry over instead of resetting. Credits apply to this site only and are not shared with other sites.
Prices shown are USD baselines; final currency, taxes, and discounts are determined by Paddle for the checkout location.