Publish and versions

How to mint a published version, what that version freezes, and how to roll back to an earlier one.

Publishing compiles the whole project strictly and, if it passes, mints a new immutable version. Readers on your share link get the version marked live. You keep editing the draft underneath.

Publish a version

Open the dialog

Press Publish at the top right of the editor, or Ctrl K (⌘ K) then "Publish…". You need the editor role or higher; a viewer never sees the button.

Press Publish now

The server snapshots every chapter, compiles them together, and writes the bundle. The status line under the button says "Published." when it worked.

A failed compile creates no version and changes nothing that is live. The dialog lists the problems under a heading like "3 problems to fix first", each naming its place as Chapter › Scene. Clicking one closes the dialog and lands you on the beat.

Copy the link

Once a version is live, the Share link field holds the URL and Copy link puts it on your clipboard. See Share links.

The strict rule that only bites at publish

Every scene where play can stop must name an ending. "Can stop" is decided statically: a scene with no unconditional outgoing edge can terminate, because one day no condition will match. If such a scene names no ending, publish fails with MISSING_ENDING and the message tells you to mark an ending or add an unconditional edge onward.

The mirror image also fails: a scene that names an ending but always routes onward raises UNREACHABLE_ENDING, because the ending could never be reached.

Mark endings in the Stage tab. Details are in Endings.

If the publish fails with something other than a compile problem (you were signed out, the server hiccuped), the dialog says so and tells you the live version is unchanged. Reload and try again.

What a published version pins

A version is one compiled bundle, frozen. It carries the whole story as readers receive it: scenes and beats, the flow graph, cast members and their looks, stage directions, variables and conditions, HUD widgets, the theme, endings, the story title, the mature flag, and a manifest of every asset the story uses. Nothing in the version reads back to the draft.

That is why editing after a publish is safe. Your next paragraph does not reach anyone until you publish again.

Publishing also counts as an edit, so the project's "last edited" time on the projects hub moves.

The version list

Every publish stacks a new numbered version, v1, v2, and so on, and exactly one carries the live badge. Each row shows when it was created.

Make live points the share link at that version instead. This is your rollback: publish freely, and if v7 turns out to be a mess, make v6 live again in one click.
Download bundle saves that version as a JSON file named <story-title>-v<n>.json, with absolute asset URLs so the file works outside this app. Available for every retained version, not just the live one. See Bundle format.

Retention

How many versions survive depends on the owner's plan. On the free plan the last three are kept and older ones are pruned on each publish. Paid plans keep every version. The numbers live in Plan limits.

Retention is not housekeeping. A reader's save pins itself to the version it started on, and it can only be loaded while that version is still servable. When an old version is pruned, saves made against it stay in the reader's browser but stop being loadable, and their save list marks them "other version". If you are on the free plan and readers are mid-story, publishing three times in an afternoon will strand them.

Publish v1 rougher than feels comfortable. A live link you can send is worth more than a perfect draft nobody has read, and Make live means a bad version costs you one click.