Work management
Releases and milestones
A dated bucket of work with a moment it shipped — and the one rule that keeps the record true.
A release is something that ships, on a date, with a version. A milestone is a checkpoint the work is measured against. They are one thing in the product because they are the same shape: a named, dated bucket of work with a moment it was reached. The vocabulary differs and the arithmetic does not.
Both gather work from any project, like sprints and the backlog. A release spanning three clients and one covering a single project are the same object; which projects it touches is derived from its items rather than declared.
Shipping with work unfinished
Unfinished work cannot stay in a release
Marking a release shipped is refused while anything in it is unfinished, and the refusal names the items. They did not ship, so they cannot stay in it — otherwise the release claims to contain work that never went out, and it claims that forever, because nobody revisits a closed release to correct it.
So the release step asks what happens to them: move them into another open milestone, or take them out. Then the release goes out containing only what actually shipped, and *what went out in 2.4* stays a true answer.
And a release cannot end up empty
Where nothing in it has finished, shipping is refused outright — because taking the unfinished work out is how it would ship, and that would leave a permanent record of a version containing nothing. This was a live bug: the empty check originally ran before the move, so the remedy produced the very state the guard existed to prevent.
States are derived, not stored
There is no status column. Everything is read from one nullable date — the day it was reached — and the work in it:
| Reads as | When |
|---|---|
| Open | Not reached, no date pressing |
| Due soon | Target within a fortnight |
| Past its date | Target gone, work outstanding |
| Work done, not marked | Everything finished, nobody has said so |
| Done / Done, late | Reached — and by how many days it slipped |
The last two are the reason there is no status column: they are exactly the states a stored one goes on misreporting, because updating it is the thing nobody remembers. **Lateness is reported rather than smoothed into *done***, since it is the only figure that says whether the dates mean anything.
After it ships
- Its contents are frozen — nothing can be added or removed. That is the record of what went out on a date, and editing it after the fact is how a release history becomes fiction.
- It cannot be deleted. Deleting removes the answer, not the event.
- It can be reopened if it was marked by mistake — but work moved out on the way stays out, because moving it was a separate decision and reversing it silently would put items back into a release they were deliberately taken out of.
- The target date stays editable, because correcting a date that was wrong is different from pretending it was met.
One release per item
The same rule as initiatives, for the same reason: the question asked of a release is what shipped in it, and an item counted under two makes that answer ambiguous. The cost is that a fix backported to two versions cannot be expressed — stated here rather than discovered.