Releases, from plan to live

Work moves in releases. A release is a set of asks that are built together, tested together, judged one by one, and go live together. While one release is building, the next is being shaped: every new ask goes into the next release.

The Home

The Home is built around your releases. Four figures lead it, each with a bar for every one of your last seven days: what is building, what is waiting for a verdict, the asks written, and the releases that went live. Under them, Building now lists the asks of the release in flight that are building now — an agent at work, or CI testing an ask built on its own — with the agent, its model, how long it has run, what it has spent so far, and the rung it has reached. Beside it, Waiting for your verdict lists what is ready for your look and how long it has waited, oldest first. Then Recently live, and the Next release — the one new asks go into — with Approve the lines on an ask still a draft. Send it off is on the release's own page. On a phone, the verdicts come first.

What waits for you is one press away on every page, behind the count in the top bar (see What waits for you, and your hats).

Shaping an ask

Write an ask in one line. DoneMark drafts its lines of done when, and — when the ask changes a screen — three mockups of it, while you keep working. Each is a small picture of the screen; they appear on the ask's page. Choose the one that looks like what you mean: your choice becomes a decision the agent may not contradict, and when the ask is judged, the mockup you chose sits beside what was built. Not quite? Draft three more; the choice you already made stands.

Paste a picture of what you mean into the ask, and its three mockups are drawn from your picture: three arrangements of what it shows, in its own colours and type. Without a picture, mockups are grey wireframes. The mockups also follow the mockups already chosen on your project's other asks, so screens keep the same habits. When the agent builds, your picture comes first: the mockup you chose refines it, and where the two differ the agent follows your picture and says so. If your organisation's drafting model cannot read pictures, the ask says so rather than drawing without it.

An ask that changes no screen gets no mockups, and says so. Mockups need a drafting provider for your organisation — the drafting provider is chosen in Organisation settings. Without one, the ask says where to choose it, and nothing waits for a mockup.

The Releases page

Releases lists Next up first: the release new asks go into, each ask with the direction it serves, its four squares and where it stands. Releases planned after it sit folded under Later. Each shipped release shows its notes for the people who use it, with Publish these notes, Copy as Markdown and Take them down; a release for a product with nothing to see after a merge says Merged, never Live. Directions sit across the top on a wide screen and last on a phone. + New release opens in the page: a version, a name, the date you aim at (your aim — a claim), and the asks in no release yet to put in it, drafts included. The register is the second tab.

A release's own page has its stages along the head — Planned, Sent off, Building, Judging, Live — with the date you aim at and who sent it off. Beside its asks, Your verdicts lists each ask's look and the one act of the stage. Under the asks, The release's CI test says what CI reported at the commit it tested: each failing check by name, and the run on GitHub. What happened lists what was done to it, newest first.

Try it before you judge

On a release, Try it before you judge runs it as CI tested it, with sample data, so you can click around before you give your verdict.

Start it in the cloud is one press. It opens a tab of its own; the first time, GitHub asks once whether DoneMark may start codespaces for you. DoneMark then makes one on your own GitHub account (GitHub Codespaces, the smallest machine), shows the steps while GitHub sets it up, and the tab opens the app a few seconds after GitHub has it ready — about a minute and a half the first time. DoneMark uses that permission only to ask GitHub to start or stop your codespace, never to reach the app, and hands it back to GitHub as soon as the codespace is ready; you can withdraw it in GitHub's settings. The app opens only in a browser signed into GitHub as you. GitHub stops it after 30 idle minutes; pressing again resumes it in seconds, and GitHub deletes it a day after it stopped. Free hours each month, then GitHub bills you. GitHub's own page stays offered underneath, for anybody who prefers it.

On my machine gives you one line to paste in a terminal. It needs Docker Desktop, fetches the release with your own GitHub access, opens it on localhost, and tells the release page when it runs; Ctrl-C stops it and removes what it started. An ask built before CI tests its release can be tried too, marked not tested by CI yet. An ask built on its own is tried from its own page, at the commit its attempt made. Trying is never needed to judge, and never counts as evidence.

An app made from the web template carries the start file from its first day. An app without one shows Draft one: an ordinary ask that gives it one, which goes through a release like any other. Try it needs a GitHub repository for now.

When something goes wrong while you try it, you see it in words, without reading a log. An app from the web template shows a thin DoneMark strip at the bottom of every page while it is tried — never once it is live — listing what went wrong on the server and in the browser, newest first. The card says the same under What the app said, with Copy for my look; on an ask's page the press is Put it in my look, which adds the lines to your Not quite reason. Only each error's words, time, method and path reach DoneMark — never page contents or anything typed. An app whose start file predates the strip is offered Draft one for it.

The app's own journeys run on the app CI starts from the start file, on every release, whatever the host: a journey that breaks shows on the line it covers, before anybody presses it. Only what a journey walks is walked — a template app starts with one, that its home page opens — and an app whose CI predates this walks none until its CI is brought up to date.

Planned

A release starts planned. Its page lists its asks, in the order they will be built — move one with ↑ and ↓ while it is planned; once sent off, it is built in the order it was sent — and — under Missing before it can go — anything that has to be done first:

• the safety note of a risky ask, not yet approved;
• an agent key that has not answered a test;
• an ask whose lines of done when do not all say how they will be seen;
• an ask with mockups and none chosen yet (Choose a mockup for …).

An approved ask that is in no release yet counts as part of the next one, and joins it when it is sent off.

Send it off is offered once nothing is missing. Past the organisation's monthly budget it asks first, and goes only after Start anyway.

Building

Sent off, the release is built ask by ask, in its order, on one branch; then CI tests the whole release once. It has 180 minutes per ask, as one window — a release of four has twelve hours. An ask not started when the window closes goes back to be built in the next round.

A release sent off while another is building waits its turn, and starts by itself when that one is done — there is nothing to press.

A release also waits while the last change is still going in: DoneMark builds nothing new until it is live, so new work starts from what people actually have. The release page then names that change, says why it waits and since when, and the top bar says Stuck once it has waited over 15 minutes. If the change merged and your app is not hosted anywhere yet, It isn't hosted yet: carry on lets the queue go on. With no live address set, a merge is where the wait ends.

Nothing starts on its own otherwise: the queue no longer builds single asks by itself. A single ask can still be started by hand, from its own page.

If three attempts end the same way in a row, or the agent's account runs out of quota, the release holds where it is and the page says why. A pause — yours, or the queue's own — holds the release's next asks too.

Judging

You can look at an ask as soon as it is built, while the rest of the release is still being built: Judge beside it under Your verdicts opens it, and you say Looks right or Not quite with a reason on the ask's own page. Until CI has tested the release, the ask says Looks right · CI has not tested it yet. When CI has tested it, a "looks right" stands if every check passed; if one failed, you are asked again, and told which check. A "not quite" stands either way. Nothing is sealed on a look alone.

Each ask is judged on its own page. Judge on the home, or on the release, opens it: Release 1 · ask 1 of 2 to judge, the mockup you chose beside what was built on the running copy, the proof for each line of done when, and a reason. Then Looks right or Not quite — or the keys S and N. Your look is held on the ask, and sealed when you release the whole release. The next ask to judge opens by itself; after the last one, the release opens with what is left to do. J and K move between the asks still to judge.

When CI has tested the release, each ask not looked at yet is ready to judge: its evidence, its picture, its lines of done when. A look given on a version CI has since tested again is asked again.

If anything is not quite, Fix it in this release builds those asks again on the same branch with your words, and the release is tested again.

Live

When every ask looks right, Release — Seal the 4 and put them live — seals each ask as its own numbered record, with your name and reason, and the release goes live in one merge. The seals are written all or none: if one cannot be written, none is, and the release still waits for Release. A release holding a risky ask is sealed, and goes live once that ask's release is approved by another judge — or, with only one judge, by the only judge, and the record says so.

Stopped

A release stops when main moved and it no longer merges cleanly, or when CI could not test it twice. Its page says why.

When main changed the same places the release did, the release keeps its asks and its turn — nothing behind it starts — and its page offers two presses:

• Bring it up to date and test again: one short agent attempt brings today's main into the release and settles the clash, keeping both sides' work; then CI tests the release once and you judge as usual. Nothing is built again.
• Build them again in the next release: its asks move on, and are built from the start there.

Each ask in the release says the same on its own page: what landed on main, the files both changed, that nothing is lost, and Bring Release N up to date. An ask built on its own says it needs building again on today's main, and carries Dispatch an attempt with its limits.

Any other stop moves what the release did not deliver to the next release at once — an ask never started, and one built but never tested, which is built again there — so the next release's page offers it with Send it off.