Versions and publishing

Every save in Quillet appends a version that never changes again, and publishing is a separate act that tells readers which of those versions to see.

Why saving and publishing are two acts

If a save went live at once, you could not stop halfway through a change, ask someone to read it, or fix a typo in a sentence you are still writing. Quillet separates the two acts so that you decide what becomes live and when. Save as often as you like: your site serves the same version until somebody publishes another.

A version also never changes after it is written. That is what makes History a record you can trust, and it is what lets a site ask what was live at any past moment. It keeps a version's content hash stable, too, and that hash is what the delivery cache and the command line's diff both compare.

What a save, a publish and a restore change

Saving never changes what readers get: delivery serves only the version marked live, and a restore adds a version instead of rewinding.

Saving

A save that changes the content appends a version with the next number, who wrote it and an optional note. A save that changes nothing, such as reformatting the same JSON, adds no version. The pill in the page bar tells you where the document stands: Draft while nothing is published, Published while the live version is the latest one, and Changed since published once you have saved past it.

Publishing

Publishing marks one version live and retires the one before it at the same instant. The delivery cache for that document is cleared in every locale, because every locale may fall back to it. Unpublish clears the live version, and delivery stops serving that locale of the document.

A publish can name several documents. They go live in one transaction, at one instant, as one decision. That is what lets a component and the documents measured against it be published together, and it is why a webhook sends one event for the whole batch.

Seeing what a publish changes

A document can be referenced by others. When twenty pages share a component, publishing the component changes all twenty, and none of them is published again. So before you confirm, the publish dialog shows the version that will go live, the live documents that include it, the locales that read it by fallback, and any problem that would refuse the publish. The dialog publishes the version you reviewed. If someone saves in the meantime, the publish is refused and you are asked to look again.

Restoring

Restoring an old version does not rewind history. It writes the old content as a new version, which History labels "Restored v2", and you publish that version when you are ready. A restore is checked against the component in force today, so an old body that no longer fits is refused, with the reason.

How to

curl -s -u '<keyId>:<secret>' \
  'http://localhost:3000/d/v1/<project>/<env>/content/<key>?at=2026-10-01T09:00:00Z'

Limits

• There are no named releases, no scheduled publishing and no approval step.
• The impact summary follows references two levels deep and lists at most 200 documents per level. A document that only links to the one you publish is not listed.
• A publish of several documents is all or nothing: one refusal refuses the whole batch.
• A restored version is a draft, and it reaches readers only when it is published.
• Conflict detection on save covers the content, not the title, the tags or other metadata.

Related

• Publishing and history: publish, unpublish and restore, step by step.
• When two people edit: what happens when a save is refused.
• Components and pages: why publishing one document can change another.
• Delivery: what a publish does to the cache.
• Integrating a site: how your site hears about a publish.