Releases

Releases group related entries into a planned deployment. They have a lifecycle — from planning through to release — and can include approval workflows, quality checklists, and GitHub evidence.

Creating a Release

1. Open a project and click Releases.
2. Click New Release.
3. Fill in:
   • Name — e.g. "Sprint 42" or "v2.4.0".
   • Version — optional semver string (e.g. 2.4.0).
   • Type — Major, Minor, Patch, or Hotfix.
   • Start Date and End Date — the planned delivery window.
   • Description — what this release covers.
4. Click Create Release.

The create release modal with name, version, type, and date range fields.

Release Lifecycle

Releases move through these statuses:

Status	Meaning
Planning	Scoping in progress
Active	Development underway
In Progress	Same as active; interchangeable
Testing	QA / UAT in progress
Completed	All work done, awaiting sign-off
Released	Deployed to production
Archived	Historical record; no further changes

Admins and project owners can advance the status manually from the release detail page.

The release detail page showing the status progression bar and current stage.

Adding Entries to a Release

Entries are linked to a release in two ways:

• Drag and drop — from the Entries tab, drag an entry card to a release in the sidebar.
• Entry detail — open any entry and select a release from the Release dropdown.

The entry detail panel with the Release dropdown open and a list of available releases.

Quality Checklists

Releases can include checklists to track release readiness tasks (e.g. regression test passed, staging sign-off received).

1. Open a release and click Checklists.
2. Click Add Checklist.
3. Give the checklist a name (e.g. "Release Readiness") and add items.
4. Team members tick off items as they are completed.

A checklist named 'Release Readiness' with several completed and pending items.

Approval Workflows

Releases requiring formal sign-off can use approval workflows:

1. An approval instance is triggered on the release (manually or automatically based on a template).
2. Designated approvers receive email notifications.
3. Each approver can Approve or Reject with an optional comment.
4. All approvals must be granted before the release can proceed to the next stage.

See Approvals for a detailed walkthrough.

Release Evidence

For compliance purposes, each release can generate a signed evidence package that captures:

• The approval chain with timestamps.
• Linked commits and CI results from GitHub.
• Checklist completion status.
• A completeness score (0–100).

Admins and partners can retrieve the evidence package via the Release Evidence API.

The evidence panel showing approval chain, linked commits, and the overall completeness score.