Mergelay compared with GitHub’s auto-generated release notes

• Free, and already there

  Nothing to install, nothing to authorise, no second bill. If you are tagging releases you already have this feature.

• Generated from the merged pull requests

  The Generate release notes action composes the entry list from the pull requests merged since the release you compare against, with the contributors and a link to the full changelog. A Previous tag dropdown lets you choose that comparison point.

• Configurable, and versioned with the code

  A .github/release.yml file creates categories and lists the labels that fall into each, and excludes pull requests by label or by author login. It lives in the repository and is reviewed like any other file.

• Attached to the tag, and public if the repository is

  The notes sit on the Releases page against the tag they describe, which is a permanent, linkable address you did not have to build.

• Machine-readable

  GitHub’s REST API lists a repository’s releases and returns one by tag or by id, so anything downstream can read them without scraping.

• People who watch for releases are told

  A watcher can subscribe to release events specifically, and GitHub notifies them. This is a real distribution channel, not an empty one.

The verdict that follows from all of that: if the people who need to know already watch your repository, GitHub’s own release notes are probably enough, and Mergelay would be a second tool for no gain.

• The entry is the pull request title

  If a title reads fix(api): rename invoice fields, that is what your reader gets. Nothing reads the diff to work out what the rename means for someone using the product.

• Publication is the repository page

  Getting the same text into a customer email, a Slack channel, Microsoft Teams, a CMS or a social account is a workflow you write and then maintain. GitHub does not send it for you.

• Visibility follows the repository

  On a private repository only people with access ever see the notes, however well written they are.

• Review is authorship, not approval

  A release can be saved as a draft and edited before it is published, by whoever is creating it. What does not exist is reviewer routing, an approval bound to an exact revision, a record of who approved what, or a way to require a second person.

• It reads the merge, not only the title

  The description, the labels, the commits and bounded, sanitised patches go into the analysis alongside the title, and the result carries its evidence and its assumptions.

• It writes one draft per channel

  An internal brief, a Slack or Teams message, a release-note record, a customer email and a social post per connected network — each written for its own reader from one source of truth.

• It groups related merges

  An Update carries an ordered list of up to ten sources, primary first, so three merges that made one migration work are told as one release rather than three.

• The approval is a record, not an edit

  One decision binds every enabled draft and destination of one exact revision, any content edit creates a new revision that must be decided again, and the decision is attributed and audited.

• Delivery is accounted for per destination

  One outcome is recorded for each destination and a failure is retried alone, so fixing an email does not repost to Slack.

• An unsupported claim is flagged, not shipped

  When the grounding validator cannot support a sentence the model wrote, that sentence is marked on every decision surface and can never be published by an unattended path.

Mergelay prices are per workspace, per month. USD, excluding VAT and sales tax — calculated and charged at checkout by Polar Software, Inc., our merchant of record.