The changelog is only one place the news has to reach
A public changelog answers a useful question: what changed? The communication job is wider. A customer needs to know why the change matters and whether to act. A teammate needs the operational context that would be noise outside the company. A social reader needs one clear outcome, not a miniature technical document. Writing one entry and pasting it into all three places preserves the words while losing the audience.
Mergelay starts before the blank editor. It watches the repositories you authorised, keeps routine maintenance out of the proposed selection and groups related merges into one Update while the evidence is still attached. Pull requests, commits and diffs remain available beside the draft, so a claim can be checked against what shipped instead of reconstructed from somebody’s memory on release day.
The result is not an automatically published wall of commit messages. It is a set of editable drafts that share one source and serve different readers. You choose which destinations belong to the Update, remove anything that should stay quiet, edit the wording and approve one exact revision. A later edit creates a later revision and asks again before customer-facing communication leaves.
One release, written for the reader in front of it
The source stays stable while the purpose changes. That is why each destination receives its own draft rather than a shared block of text with a different icon.
| Destination | What the reader needs | What Mergelay prepares |
|---|---|---|
| Your changelog or CMS | A durable account of the outcome, with enough context to remain useful after launch day | Private Markdown to copy, or content to pass to your own CMS through an automation webhook |
| Customer email | The consequence for the customer, who it affects and one sensible next action | A branded email draft with the approved claim and the destination you selected |
| Slack or Teams | Internal context, rollout implications and the detail colleagues need to support the change | A concise team brief sent to the channel-bound webhook you connected |
| Documentation | Instructions that remain discoverable when somebody meets the new behaviour later | A documentation draft or webhook payload for the system that already owns your docs |
| Social | One reason to care, expressed within the network’s format rather than as a pasted changelog | A network-specific post for the social destinations enabled on that Update |
A destination can be disabled on one Update without changing the others. Choosing “public” or “internal” is a publishing decision, not a request to rewrite the source by hand.
How a release becomes an update people can follow
The workflow removes repeated reconstruction, but leaves the editorial decision visible.
- 01Watch only the repositories in scope
The GitHub App receives events for the repositories you granted. It does not gain access to the rest of the organisation by implication.
- 02Separate product change from repository upkeep
Dependency bumps, bot-authored work and routine chores are flagged with the reason and stay out of the default selection while remaining available if they genuinely matter.
- 03Group the changes that tell one story
Related merges accumulate in an Update that is still open, rather than creating a new announcement for every pull request.
- 04Prepare the enabled channel drafts
The public record, customer email and internal brief are generated from the same evidence, each with its own editable wording.
- 05Approve and deliver the exact revision
The decision names one revision and all of its enabled destinations. Delivery records one outcome per destination, so a failed email can be retried without posting to Slack twice.
Internal communication is the one category a workspace may configure to publish automatically. Customer email and social posts remain held for a person.
What the workflow keeps that a blank changelog cannot
- Evidence beside the claim
A reviewer can inspect the pull request, commit or diff supporting an important statement before approving it.
- A boundary between audiences
Internal detail can stay in the team message while customer wording stays focused on the consequence outside the repository.
- One named revision
Editing after review never silently inherits the earlier approval; the changed draft becomes a new decision.
- A receipt for each destination
Activity records the attempt and outcome for the place that was meant to receive it, including a targeted retry after partial failure.
What this changelog tool does not replace
These boundaries matter because “changelog software” often means a much larger product category.
- Mergelay does not host a public changelog page, an in-app “What’s new” widget or a subscriber portal. It prepares private Markdown and can pass the result to your own CMS or automation; the indexed public URL remains yours.
- It is not a roadmap or feedback board. There is no voting, idea intake or automatic notification to people who requested a feature, so a feedback-led product suite remains a separate system.
- It does not discover customer segments from product usage. Email destinations use the recipients you supply, and there is no preference centre, suppression list or unsubscribe machinery.
- A generic GitHub-to-Slack event stream remains available from GitHub itself. Mergelay is for a reviewed release message with audience-aware wording, not for mirroring every repository event.
Questions
Does Mergelay host my public changelog?
No. It prepares a private Markdown release-note record that you copy to the surface you own, or pass to your CMS or automation through a webhook. If you need an in-app widget and a hosted public page from the same vendor, Mergelay is not that product today.
Can the same release go to customers and the team?
Yes, as separate drafts. The customer email, release-note record and internal message share the same evidence but keep their own wording and can be enabled or disabled independently for the Update.
Will every merged pull request become a public update?
No. Repository upkeep is flagged and left out of the default selection, related work can be grouped, destinations are chosen per Update and customer-facing publication still needs approval. A merge is evidence to consider, not permission to announce.
What happens when only one destination fails?
Its failure is recorded separately and the retry targets that destination alone. A successful Slack post is not repeated because the email provider failed, and a successful email is not resent to repair a webhook.
Where to read next
- Product update emailHow to turn a shipped change into a customer consequence and one next action.
- GitHub updates in SlackWhy a reviewed team brief is different from raw repository notifications.
- Automated product updatesWhere automation stops and the human decision begins.
- PricingBoth plans, and what the plan actually changes.
Turn the next shipped change into every update it needs.
Your first Update is free. No card required.