Tasks need a destination
A backlog with no version attached only accumulates. Every item is equally deferrable, because nothing is waiting on it. Scopes, phases and versions exist to fix that: a task belongs to something that ships, and that something has a state you can look at.
A scope is a release the project could stop at and still be coherent — not a milestone in a burndown chart. Framing it that way makes the question "could we ship this now?" answerable, which is the question that ends projects.
Release notes come from what shipped
When a version is ready, DevDeck drafts its notes from the work that actually closed it: the tasks in the version and the commits that finished them. You edit the draft — it is a starting point written from evidence, not a generated file nobody reads.
This is also the second reason to name task ids in commit messages. Notes assembled from memory describe the version you meant to ship; notes assembled from commits describe the one you did.
Subtasks and the shipping rule
A subtask never ships later than the task it belongs to. Closing a parent accounts for the work beneath it, so a shipped version cannot quietly leave orphaned children behind it — the commonest way a "finished" release turns out not to be.
Release approval
For teams, a version can require a chain of sign-offs before it ships, recorded against the version itself. It replaced an earlier proposal-based model: what a team actually needed was agreement that this version is ready, not a second queue of proposals to triage.
Solo use needs none of this, and nothing asks you to set it up.
Where it stops
DevDeck records that a version shipped. It does not publish it, upload it to a store, tag your repository or notify anyone outside the app.