Versions and publishing

Publishing moves a pointer. Rolling back and rolling forward are the same operation.

A version is a server-assigned positive integer, rendered v1, v2, and so on. The client does not choose it: the server reads the current record and increments.

Versions are immutable once written. A correction is a new version, never an edit of an old one.

One version is live at a time

An artifact serves exactly one version — its published version. A new deploy publishes itself, so deploying feels like deploying. Publishing any other version is a separate, deliberate act.

Because nothing is deleted to make room for anything else, publishing is a pointer move rather than a rebuild. Rolling back and rolling forward are therefore the same operation, and neither is a one-way door. There is no "restore" that is slower or riskier than shipping — going back costs exactly what going forward cost.

Previewing an unpublished version

GET /{id}/_v/{n}/ serves version n directly. For the owner that works for any version; for anybody else it only works when n is the published one — otherwise unpublished drafts would be readable by URL, which would defeat the point of publishing being a choice.

What this buys you

  • A deploy that went wrong is undone by publishing the version before it, in one action.
  • Nothing discarded disappears. A superseded version stays reachable rather than being folded away, and the history says which agent wrote it and when.
  • The dashboard can show you which version a given screenshot, view count or error belongs to, because the version is part of the record rather than a detail of the last write.