Changelog

Write release notes per project and publish them to your portal.

The changelog can be turned off per project — see Project Settings.

• Lifecycle: entries are draft → scheduled → published. Only published entries appear on the portal (and in its RSS feed).
• Versions: entries carry a semver-style version (e.g. 1.4.0).
• Labels: tag entries (e.g. New, Improved, Fixed) for scannability.
• Translations: entries can be machine-translated into your project’s other locales.
• Email announcements: published entries can be emailed to subscribers; monthly email volume depends on your plan (Pro: 5,000, Team: 25,000). Pro

Creating a changelog entry

1. Click New Entry in the project’s Changelog page
2. Enter a title (required) and body (optional, Markdown supported)
3. Set the version (e.g., 1.4.0) — must be unique per project
4. Add labels (New, Improved, Fixed) for categorization
5. Choose status:
   • Draft — saved locally, not visible to users
   • Scheduled — will publish at a future date/time
   • Published — visible on the portal and in RSS

Draft workflow

• Drafts are only visible to team members
• Edit drafts anytime before publishing
• Use drafts to prepare release notes in advance

Translations

• Changelog entries can be authored in multiple locales
• When a visitor’s language matches, they see the translated version
• Machine translations can be accepted or rejected per entry

Publishing

• Published entries appear on your portal’s changelog
• They’re included in the RSS feed for subscribers
• The published_at timestamp is set automatically

Audience

Each changelog entry targets an audience:

• All users (default) — public: shown on the portal, included in the RSS feed and the public API, and (on publish) emailed to your changelog subscribers and the voters of any linked posts.
• Beta testers only — private to a beta program you pick. The entry is shown on the portal only to that program’s verified, enrolled testers, is excluded from the RSS feed and the public API, and (on publish) emails that program’s testers instead of the general audience.

Pick Beta testers only and choose the program when creating or editing the entry. You need at least one beta program on the project first (see Beta Testing). To promote a beta entry to everyone later, edit it and switch the audience to All users — it then becomes publicly visible. (An entry emails only once, when first published, so promoting it does not re-send the announcement.)