Releases

Releases group issues that ship together under a version name or target date. Releases are team-scoped and require the releases capability and read permission.

When to use a release

Use a release when:

• You ship on a version cadence (v1.2, v1.3, …)
• Multiple issues must go out in one deployment or launch
• Stakeholders need a single place to see launch scope and status

Cycles plan when work happens; releases describe what ships together. An issue can belong to both a cycle and a release.

Where releases appear

Under each team in the sidebar, open Releases (/releases?team=…). The list shows releases for that team only.

Workspace-level release settings live under Settings → Features → Releases (workspace admins).

Create a release

Team members with create permission:

1. Open Releases for the team.
2. Click New release.
3. Set name, target date, and initial status.
4. Add issues from the release page or from issue detail.

Add issues to a release

From an issue:

• Set Release in the issue properties panel
• Bulk-select issues on a list and set release

Issues must belong to the same team as the release.

Release lifecycle

Track status through planning, active development, and shipped states. Exact status names depend on configuration; keep release status current so portfolio and development integrations reflect reality.

When a release ships:

• Mark it complete per team convention
• Ensure linked issues are in a completed workflow status
• Publish any release notes or documents attached to the release

Development links

When GitLab or GitHub development links are enabled, merge request and deployment status can surface on linked issues. Configure integrations under workspace or team settings.

Permissions

Read access requires releases:read on the team. Creating and editing releases requires create/update permission. If Releases is missing from the sidebar, ask an admin about capability and permissions.

Next