Release management
On this page
Release management
Lock a finished MVP as the baseline, then build only what changed. · Optional · Pro plan
Once your first version is built and passing, you will want to keep going: add things, change things, remove things. Release management keeps that honest. It records what "done" looked like, so your agent builds the difference instead of rebuilding the app.
Rolling out. The Releases tab is reaching accounts gradually. It sits beside Plan and Track on the Development page, and it is included in the Pro plan and above. If you don't see it yet, it hasn't reached your account.
What a release is
A release is a version of your product, named MVP1, MVP2 and so on. The one you are working on is active. When you start the next one, the current release becomes locked: VibeMap keeps a snapshot of your whole spec at that moment, including how each criterion was verified. That snapshot is the baseline.
A release only scopes what gets built. Your spec is always the current truth, so there is no special "retired" state: if you delete a story in MVP2, it is simply deleted, and the baseline remembers that it used to exist.
Start the next MVP
- Open Development, then the Releases tab.
- Click Start MVP2.
- Confirm. The dialog tells you that this locks MVP1 as the baseline and that, from then on, VibeMap tracks only what changes. You can rename the new release before you confirm.
Until MVP2 exists there is nothing to compare, so the tab explains this in one line and shows no work list.
The work list
After the lock, the tab shows the work for the active release, compared against the baseline:
| Group | What it holds |
|---|---|
| New | Things that did not exist in the baseline. |
| Modified | Things that changed. Each one lists its changed fields as before and after, and the commit it was last built at. A criterion that had already passed goes back to Ready so it can be rebuilt. A story or feature appears here, marked as such, when a criterion under it changed. |
| Removed | Things that were in the baseline and are gone now. Each one lists the code that was linked to it, so you know what to delete. If no code was linked, the entry says so. |
The list is capped for very large changes. If more passed criteria need reopening than one refresh handles, the tab tells you how many are still to come.
Planning and approving
- Plan sprints for this release builds sprints for the new and modified criteria only, plus a final cleanup sprint for the code to delete. Earlier releases keep their sprints. It asks you to confirm because it replaces this release's sprints.
- Approve all N awaiting approval approves the release's draft criteria one by one, with progress, and tells you if any fail.
Then your agent works through the release exactly as it did the first time. See Watching progress.
Good to know
- A release does not change what Version history records. Every change is captured on every plan; only restoring an earlier version needs Pro. See Reverting changes.
- You cannot restore a version older than a locked baseline, because that would undo shipped work. The restore dialog tells you the nearest version you can restore.
What's next
- Watch the build → Watching progress
- Plan the sprints → Sprint planning