Releases

A release is a version of your product that goes out on a date. In devBoard, a release is a name, a target date and the tasks tagged for it. You mark it shipped when it goes out. That is the whole feature.

How it works

• Each project has its own releases. Open the project and go to Releases.
• A release has a name, like 1.4.0 or Q3 launch. The target date is optional.
• Tag a task for a release from its Release field. Every level of work has one.
• The release that goes out next sits on top, marked Next up. Later ones sit under it.
• Shipped releases sit lower down, under Already shipped, with the day they went out.
• Each release shows how many of its tasks are done. It counts the tasks the app has loaded, and the line says so.
• Press Mark shipped when it goes out. The server stamps the date. Press Reopen if you marked it too soon.
• Delete a release and its tasks only lose the tag.

Owners and admins create, rename, ship and delete releases. Members tag tasks for them. Guests can look.

Many small teams use releases in place of sprints. Name one Sprint 12, set its target date to the last day, and tag the work. A saved view with that release as a filter shows what is still open.

You can also plan from an AI assistant. MCP is the open standard that lets an AI assistant use other tools. Over MCP, create_release plans a release and ship_release marks it shipped.

An example: Luka, Mira and Ivan

Luka, Mira and Ivan ship their mobile app every two weeks. Mira is the admin. She makes a release called 2.3.0, with a target date on Friday. At planning they tag nine tasks for it.

On Wednesday Ivan opens their shared view, "Left in 2.3.0". Three tasks are still open. One is a crash fix that will not make it, so Luka moves its release to 2.4.0. On Friday the build goes out to the stores, and Mira presses Mark shipped. On Monday, 2.4.0 is on top of the Releases screen, marked Next up.

What it does not do

• No sprints, burndown charts or velocity. A release with a date is the closest thing.
• No release notes or changelog. Write those where you already do.
• No link to a build or a store version.
• One project per release. A release cannot span two projects.
• The count on the Releases screen covers loaded tasks only. For the full list, use a saved view.

Set it up

An admin opens the project, goes to Releases and presses New release. Then tag tasks from their Release field, or group them first into epics. An epic is a big piece of work split into smaller tasks. The guide on how to plan a release walks through a full cycle. Or see all devBoard features.