Releases
For engineers and project managers.
A release is a named version of one project’s work (“7.0.6”) with an optional date, an optional git tag, a state (planned, released, cancelled) and notes. An issue names the release that fixes it.
Version numbers are unique inside a project, so two projects may both ship a 7.0.6.
Planning
Each project has a Releases section: make one, edit it, see what is in it. An issue is planned into a release from the issue itself, from the list in bulk, or by dragging its card on the board, where the columns are the versions.
The release lists its issues grouped by label (unlabelled ones by whether they are finished), with the number of client tickets waiting on each. That count is the useful one: it tells you which fix people are actually waiting for.
Notes, drafted
Marking a release released gathers its material and asks the assistant once for two drafts:
- a short customer-facing summary of what changed and why it matters;
- a plain technical changelog.
The material is the issues fixed, with their labels and ticket counts, plus, when a repository is connected and the release names a tag, the commits between the previous release’s tag and this one.
A release with no tag, or a desk with no repository at all, drafts from its issues alone and reads perfectly well. The page says which it did.
Both drafts are editable before anything happens and are saved on the release, so you can leave and come back. Issue titles and commit subjects are treated as untrusted material in the prompt, a commit subject cannot instruct the model.
Drafting obeys the brand’s AI switches, the per-agent AI permission and a daily ceiling.
Publishing
Then one confirmation with four tick boxes, none of them ticked:
| Tick | What happens |
|---|---|
| Announcement | The summary goes on the brand’s announcement bar, dismissible, expiring on its own |
| Status entry | A completed maintenance entry on the status page: no impact, nothing emailed |
| Answer the tickets | Every still-open ticket linked to an issue in the release gets the reply |
| Knowledge note | The notes are added to the knowledge base, so the assistant can answer about the release later |
Each runs the feature that already exists rather than a parallel implementation. Confirming with nothing ticked marks the release released and does nothing else, and the result says so plainly.
A client who reported two of the release’s faults is answered once. Closed tickets are left alone. Tickets in departments you do not work in are skipped and counted, so the total is honest.
Who may do what
- A contributor makes and edits releases.
- A project manager publishes.
- Posting to the brand’s announcement bar or status page additionally needs the administrator gate that posting either by hand needs, so a project manager who is not an administrator can still release, answer the waiting clients and write the knowledge note.
Advice
- Plan into versions as you go, not at release time. The board makes this nearly free, and it is what turns the notes draft from fiction into a summary.
- Read the customer summary as a customer. The draft is usually right about the facts and too keen about their importance.
- Tick “answer the tickets” last. It is the one that emails real people, and the confirmation shows exactly how many.