Changelog

Changelog publishes product updates through the public portal and widget.

Create a Release

A release can include a title, excerpt, rich body, version, release date, cover image, and linked feedback. Keep it as a draft until it is ready for customers.

Managani can suggest a complete draft or improve the excerpt and body separately. Review generated content before publishing.

Publish and Notify

Publishing makes the release available through the portal, widget, public search, and RSS feed. You can then notify selected recipients and changelog subscribers by email.

Published releases support anonymous browser-scoped emoji reactions and signed-customer comments when those options are enabled. Unpublishing removes the entry from public results without discarding its original publication and release dates.

Connect Customer Requests

Attach shipped feedback to the release. The public experience can then link customers between the original request and the update that delivered it.

Use the short /c portal URL when sharing the changelog. It redirects to the canonical /changelog page and preserves query parameters.

Write a Release Customers Can Use

Lead with the customer outcome, then explain where to find the change and any action required to use it. A title should identify the feature or fix clearly. Use the excerpt for a short overview and the body for instructions, examples, and relevant limitations. Avoid using internal ticket names as the only explanation.

Review any AI-generated draft against the delivered behavior. Confirm version information, release date, links, and the feedback items attached to the release. A draft is a useful place to collect these details while the team verifies the change.

Treat publication and email notification as separate decisions. Publishing makes the update available on customer surfaces; notifying sends it to the selected audience. Check the published entry before sending the announcement, including its cover image and links. If an entry needs to return to draft, use unpublish and review the content before making it public again.

GitHub Announcements and Resolution

Publishing a changelog queues every linked GitHub issue to close as completed, including issues linked through merged feedback. Managani posts the changelog text and its public link as an announcement comment on the target issues. Pending public feedback exports are resolved first. If there are no target issues, Managani creates one issue and its corresponding hidden feedback record and closes the issue as completed. These changes use the project's connected repository; failed issue updates remain pending for retry.

Changelog prose stays separate from the issue title and description. Editing a published entry updates its existing announcement comments without closing issues that were manually reopened. Unpublishing retains the posted text, link, and issue resolution while pausing exports of draft prose. Republish closes the linked issues as completed again and updates the same announcement comments instead of creating duplicates. A link to an unpublished entry no longer exposes that draft through the public changelog. Connecting a repository does not create issues or announcements for the historical changelog archive.

The editor's GitHub issue resolution control applies to all linked issues. Closed closes every target as completed; Open reopens every target. The aggregate state is Closed only when all targets are closed. The control is disabled until target issues exist. Changes arriving from GitHub update the displayed aggregate without triggering additional close/reopen commands.

Discussion comments added through the changelog sync to its target issues. The changelog displays a shared discussion without repeating mirrored copies of the same reply. Private repository discussions are available to project admins and are omitted from public changelog responses. Announcement comments intentionally retained after unpublishing remain on GitHub independently of the entry's publication state.