Releases
Track which version of which service your work ships in
A release is a version of a service, such as checkout-1.4.2. You put the tasks and epics that build it in the release, attach the change request that deploys it, and Decuga keeps the release’s status up to date as the work moves: from the first task started to the day the change request completes. When it ships, it can write the changelog for you.
What a release is
| Field | Notes |
|---|---|
| Service | Free text, up to 100 characters. As you type, the services you have used before are suggested. |
| Version | Free text, up to 50 characters: 1.4.2, 2026.10, v3, whatever your team uses. Decuga does not enforce a format. |
| Name | Always shown as service-version, for example checkout-1.4.2. Service plus version must be unique in a project, ignoring letter case. |
| Code | Like epics, each release gets a code from the project prefix, for example DT-R-3. |
| Target date | Optional. An open release past its target date is flagged. |
| Released on | Set automatically when the release becomes Released. |
| Description | Optional rich text. |
Renaming a release (changing its service or version) updates the name shown on every task, epic and change request in it.
Status follows the work
Nobody has to remember to update a release. Its status follows what happens to its work, and only ever moves forward.
Discarded is the one status you set yourself, from New or In-Progress. Released and Discarded are final.
| When | The release becomes |
|---|---|
| A task in it is started (its status is In progress). A task counts when it is in the release, or in an epic that is, unless the task names a release of its own. | In-Progress (from New) |
| It has at least one change request attached, and every attached change request is Completed. | Released, and today is stamped as its release date |
| You discard it (from New or In-Progress). | Discarded |
- It never goes back on its own: if every task moves back to New, an In-Progress release stays In-Progress.
- A change request that Failed or was Rolled back does not release it. The release stays where it is and shows a Change failed warning until another change request completes.
- Tasks alone never release it. Without a change request, a release with every task Done stays In-Progress.
- Released and Discarded are final. They take no more work, and only the description can still be edited.
- Every status change is recorded in the release’s history, by whoever caused it, or as Decuga when it followed the work.
Putting work in a release
| What | How | Rules |
|---|---|---|
| Task | Choose the release in the task’s Release card; or select several tasks on a list or board and use Release in the bar at the bottom. | One release per task. A sub-task always follows its parent’s release, so it is skipped when you select it. A repeating task’s next occurrence does not inherit the release. |
| Epic | Choose the release in the epic’s Release card or form. | One release per epic. Its tasks count toward that release. |
| Change request | Choose the release when creating the change, or in its Linked Items. | Several change requests can deploy one release. A change that has already finished (Completed, Failed or Rolled back) cannot be attached. |
Tasks in a release show a small service-version chip on cards and in lists. Putting an item in a release, taking it out, or moving it is recorded on the item and on the release.
The Releases page
Open Releases in the sidebar, under Project Management, just below Epics.
- The list shows New and In-Progress releases to begin with. Use the status chips to include Released and Discarded; each chip shows how many releases have that status.
- Each row shows the code, name, status, target (or release) date, how many epics and change requests are in it, and progress: tasks done of total.
- Open a release to see its description, progress, tasks (those that count through an epic are marked via epic), epics, change requests with their status, and its history.
- Delete appears only while nothing is linked to the release. Once work is linked, use Discard: the work stays linked, but the release takes no more.
- A shared link carries
?releaseId=and opens the release directly.
Changelog from a release
Generate changelog on a release writes a draft changelog from the release’s Done tasks: those in it directly and those of the epics in it. The release’s version becomes the changelog’s version and the title is service version. It uses the same AI release-notes writer, and the same AI quota, as writing one from a sprint.
- The button is disabled until at least one task is Done: there is nothing to write release notes from before that.
- The draft appears under Sprint Tasks → Changelog, marked as coming from a release. Edit it, then publish it as usual.
- Writing a changelog from a sprint still works exactly as before.
Automations
Release rules are set up under Task Automations, with the same trigger, conditions and actions steps as other rules.
| Details | |
|---|---|
| Triggers | “Release is created”, “Release status changes” (optionally from and to a status), and “Task moves to a different release” (optionally from and to a release, or none). |
| Conditions | On any task event: the task’s release. On a release event: service, version and release status, plus who made the change. |
| Actions on a release event | “Write a draft changelog from the release” (as the person who made the rule; it uses their account’s AI quota, and the run fails with a reason in the run history if no task is Done yet) and “Send a webhook”. |
| Actions on a task release change | The usual task actions: set status, move to a stage, assign, add a label, create a sub-task, send a webhook. |
API, webhooks & AI
| What | Details |
|---|---|
| REST API | All under /api/projects/{projectId}/releases: list, get, create, update, /{releaseId}/discard, delete, /{releaseId}/tasks, /{releaseId}/activity and /{releaseId}/changelog (POST, writes the draft). Business and above for every call. Tasks, epics and change requests carry releaseId (set it, or send clearRelease: true to remove it). |
| Webhooks | RELEASE_CREATED, RELEASE_UPDATED, RELEASE_STATUS_CHANGED, RELEASE_DELETED. Task and epic payloads carry their release. See the webhooks docs. |
| AI chat and MCP | Tools: list_releases, get_release, list_release_tasks, create_release, update_release, discard_release, delete_release, generate_changelog_from_release, and releaseId (and clearRelease) on create_task, update_task, create_epic, update_epic, create_change and update_change. Ask “what is left in checkout 1.4.2?”. |
| Activity | Release created, renamed, edited, status changes, work joining or leaving, and deletion appear in the release’s history and the project activity feed. |
Permissions
| To | You need |
|---|---|
| See releases, their progress and history | Membership of the project |
| Create, edit, discard and delete a release, and write its changelog | Manage releases |
| Put a task in a release | Update tasks (the same as editing the task) |
| Put an epic in a release | Manage epics (the same as editing the epic) |
| Attach a change request to a release | The permission to edit the change request |
| Role | Manage releases |
|---|---|
| Project Owner, Product Owner, Product Manager, Scrum Master | Yes |
| Scrum Team Member, Service Desk roles, Change Manager, Viewer | No |
| Custom roles | Only if you grant “Manage releases” in the role editor. The built-in roles above get it on their own; a custom role that was made before releases existed does not, so grant it where it is needed. |
Plan requirements
| Feature | Free | Starter | Pro | Business |
|---|---|---|---|---|
| Releases and the Releases page | - | - | - | ✓ |
| Release field on tasks, epics and change requests | - | - | - | ✓ |
| Changelog from a release | - | - | - | ✓ |
| Release automations and webhooks | - | - | - | ✓ |
| Releases in AI chat, MCP and API | - | - | - | ✓ |
FAQ
Why can I not pick a Released release on a task?
A finished release takes no more work. The pickers list New and In-Progress releases only. A task already in a release that has since shipped keeps it.
Why is my release still In-Progress when every task is Done?
A release is Released when its change requests are Completed, not when its tasks are done. Attach the change request that deploys it, and complete that. A Failed or Rolled back change request also holds it back.
Can a task be in two releases?
No. One release per task keeps progress honest. If one change ships in two versions, use one task per version.
I put an epic in a release, but a task in it is in another release. Which counts?
The task’s own release. A task counts toward the epic’s release only when it names none of its own.
Can I undo Discard, or reopen a Released release?
No. Both are final. Create a new release (a new version) instead; you can move open work to it from the Releases page, or with the Release action on a selection of tasks.
Why can I not delete a release?
Only a release with nothing linked can be deleted. If tasks, epics or change requests are in it, discard it instead: they stay linked to it.
Does attaching a change request to an approved change send it back to Draft?
No. The release is a link, but what is deployed is unchanged, so approvals stay.