Releases and changelogs

Source: tenant releases and changelogs.

Two version identitiesCopy Anchor Link

Public numbers are independent for each tenant. The first stable release is Stable 1, and each later one increments by one. Drafts, previews, and internal releases don't consume a number, and a published number is never reused. Stable N is the default human-facing name in product emails, changelogs, dashboards, and updates. The exact technical version stays available as secondary evidence.

Publishing workflowCopy Anchor Link

1. Create a release draft for the tenant and record its internal version.
2. Add a title, summary, highlights, and optional detailed notes.
3. Link the prompt-linked commits, change review, Entire checkpoint, deployment, changelog, and roadmap item.
4. Review the release against the staging build.
5. Send the approval packet to an authorized owner.
6. After explicit owner approval on the release pull request, merge the candidate into main and publish it on the stable channel.
7. Exo assigns the next public release number and publication date.
8. Verify the live version, tenant health checks, and changelog entry.
9. Send the configured changelog email, first to the owner-preview address, and keep non-secret delivery evidence.

Publishing a changelog entry records a release. It does not bypass the release pull-request gate or deploy code by itself.

Approval packetCopy Anchor Link

Changed
- ...

Removed
- Nothing.

Pressure-test / concerns
- No specific concerns.

Validation
- ...

Deployment impact
- ...

Rollback
- ...

Call out data migrations, authentication or authorization changes, destructive operations, provider changes, and tenant-specific behavior explicitly. Don't invent a concern when there is none. Approval to merge code is not approval to deploy it unless the owner explicitly grants both.

CadenceCopy Anchor Link

• Integrate task-sized commits into staging as soon as they pass validation.
• Consolidate reviewed staging commits into a release pull request instead of approval-gating every staging update.
• Don't let approved work sit unreleased without a stated reason.
• Keep staging on the same commit and configuration intended for production.
• Never report a release as live until the deployed version and health checks are verified.

Public changelogCopy Anchor Link

Off by default. When a tenant enables it, the built-in renderer exposes /changelog, and external renderers can read GET /api/content/:tenant/changelog, which returns only published, public, stable releases.