A consistent release history
Every published version receives its own shareable page and appears in a chronological project changelog that customers and teams can revisit.
Automated changelog
Automate the release workflow without giving up editorial control.
ReleaseView prepares each update from GitHub activity, routes it through review, and publishes approved releases to a clear, permanent changelog.
Approval before publication
Automation handles collection and drafting, while your team controls wording, status, and publication. Drafts and internal project data remain private.
Useful beyond the changelog
Published releases can support email communication, Slack answers, custom integrations, and questions from MCP-compatible AI tools.
Example workflow
Keep a public history without maintaining it by hand
A customer asks when an export fix shipped. Your approved releases give them a versioned page to read, and give your team a dependable record to reference.
- 01
Prepare
ReleaseView drafts an update from the changes associated with the version.
- 02
Approve
Your team verifies the facts and decides what is appropriate to publish.
- 03
Find it later
The approved release appears in the project changelog and remains available through public integrations.
Common questions
What is an automated changelog?
An automated changelog turns source activity into a structured release history with less manual collection and formatting. ReleaseView adds human review before publication.
Are unpublished releases visible?
No. Drafts, source commits, subscriber information, and project settings remain private. Only published release notes appear in the public changelog and public integrations.
Can other tools read the changelog?
Yes. Published releases are available through public web pages, a versioned REST API, and a project-scoped MCP endpoint.