Versions, history and comparisons

Every item keeps three records of its own past: a version number, a History of earlier states, and — once it is published — a released copy, the version operators actually have. They answer different questions, and they do not always move together. By the end of this page you will know what moves the version, what each record keeps, and why a History list can skip numbers.

The version number

A new item starts at version 1. The database moves it on by one whenever a saved change touches the item's words, its look or its status: the title, summary, body or status, the cover image, and for a guide its short description, hero image or colour.

Some things sit outside the version, and changing them leaves it alone: tags, guide membership, the Field operations switches, the sign-off Required switch, and the publish time.

Every status change counts, so submitting for review, requesting changes, publishing and unpublishing each move the version on by one. Autosaves count too, so a busy draft can reach a high number before anyone reviews it.

What the version is for

• Save conflicts. The editor remembers the version it opened, and writes a save only if the item is still at that version. If someone else saved in between, nothing is written and you see "This item was changed in another session". A colleague who changed only the tags or guides has not moved the version, so that does not trigger it.
• Approvals. A second approval is given on one version and counts only for that version. Publishing is itself a status change, so the database checks the approvals on the version just before the publish — the one the approvers read — and then carries them forward, with their original times, to the version the publish creates. The published version therefore still shows its sign-off. See how two-person sign-off works.
• Acknowledgments. Operators acknowledge the version they read. The compliance roster compares that with the released version — the one operators can have — not the working copy, so an edit waiting to be released makes nobody stale. See how acknowledgments work.

A print binder prints each item's version under its heading, and again in its document-control block.

History keeps what each change replaced

Whenever a save changes the title, summary, body or status, the database copies the state it replaced into the item's History: that title, summary and body, with its version, its status, the time, and the person whose save replaced it. Only the database's own trigger writes these rows: the console can read them, but it has no way to add a row or change one.

That explains the shape of the list:

• The newest state is never in it. History holds what was replaced; the current text is the item itself.
• Numbers can skip. A new cover or colour moves the version but is not copied into History, so the version before it never gets a row of its own.
• Autosaves are grouped. A run of autosaves by one person adds one row when it starts and another every ten minutes it continues. Explicit saves, restores, status changes and anyone else's edit always add their own.
• Some rows say "unknown". A row written by a scheduled publish has no person behind it, and one saved by someone whose account has since been deleted no longer has a name to show.
• It lasts as long as the item. No scheduled clean-up removes it; deleting the item deletes its History.

The released copy

A published item has two copies: the working copy the console edits, and the released copy operators receive. The released copy holds the title, summary, body, cover and — for a guide — its short description, hero image and colour. It is a single slot, not a list: every publish, and every release of held changes, replaces it. The operator app, downloaded binder PDFs and Library imports all read the released copy.

A save to a published item goes straight into the released copy only when the person saving holds Publish and the item needs no sign-off. Any other change is held in the working copy. Changes since last publish on the edit page compares the two ("Compared against v7, published …"); on a published item a difference means operators do not have it yet — it reads Not yet released, and people who hold Publish can send it with Release to operators, after any approvals the item needs. See how publishing works.

Comparing and restoring

History sits at the bottom of an item's edit page. Compare shows a past version against the item now; the compare icon on one row followed by Compare with on another compares two past versions, older on the left. Highlighted text is in the newer side, struck-through text was removed. Articles and guides are compared block by block, formatting included; the other types as a listing of their underlying data.

Restore (for people who hold Edit content) writes a past title, summary and body back. Restore published does the same with the released copy, and is unavailable while the item is still at that version. Either way:

• The current text is copied into History first, so a restore can itself be undone.
• Only the title, summary and body come back. The cover, colour, tags and guides stay as they are.
• The status never changes. Restoring an old text on a draft does not publish it.
• A restore is a save like any other: it moves the version on, so approvals given before it stop counting, and on a published item it follows the same rule as any save — released at once only for someone with Publish on an item that needs no sign-off, held otherwise.
• If someone saved the item after you opened History, nothing is restored and you are asked to look at their change first.