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.