Versioning & Rollback
Deep dives into every tool on stage
Versioning & Rollback
Every time you publish a piece of content, RoleCall creates a version — a frozen snapshot of everything in that content at that moment. Versions stack up into a history you can browse, compare, and roll back to at any time. No publish is ever truly lost.
This doc covers the full versioning system: what gets versioned, how the version history panel works, diffing, rollback, snapshots, and how versions interact with forks and subscribers.
For the publish action itself — the modal, changelog, release notes, per-field change reasons — see Publishing & Sharing.
What Gets Versioned
Versioning applies to every publishable content type:
- Characters — full character card snapshot including all prose fields, the Casting Card, alt-arts, bundled lorebook links, and tag intensities
- Presets — sampler settings, full prompt stack, categories, behavior flags, style tags
- Lorebooks — metadata plus every entry with all its settings (keys, depth, probability, group, etc.)
- Personas — content body, name, image, tags
- Prompted Responses (Guides) — content, type, category, injection role, auto-trigger flag
- Prompts — content, role, category, identifier
- Regex Scripts — script metadata plus every rule
- Series — series metadata plus the ordered item reference list
What is not versioned separately:
- Drafts between publishes — edits you make while the content is unpublished are autosaved to the live content row, but they don't create a new version until you publish. You can take a named snapshot of a draft state (see Snapshots), but drafting activity doesn't increment the version count.
- Personal overrides — if you're a non-owner who has saved overrides on someone else's character, those live in your own override layer and don't interact with the original's version history.
When a Version Is Created
A new version is created in exactly two situations:
- You publish — clicking Publish (or "Publish Draft to Everyone" from the in-chat panel) opens the Publish Version modal, computes the changelog, and creates the snapshot when you confirm.
- You take a manual snapshot — the Version History panel has a Snapshot button that captures the current draft state as a named restore point without publishing.
Small edits during drafting — typing, rearranging, toggling settings — do not create new versions. They update the live draft row. The 30-second autosave in the standalone editor is saving your in-progress draft, not creating a version.
This means you can spend weeks iterating on a character without cluttering the version history. The history only records things that were ready to share, plus any named snapshots you explicitly requested.
Where to Find Version History
The Version History panel is accessible from two places:
Standalone Editor
In the standalone editor, the Publishing Controls block (near the top of the page) includes a Version history link. Clicking it opens the Version History panel as a sidebar drawer over the editor. You can browse the history, view diffs, and roll back without leaving the editor page.
See Standalone Editors for the editor chrome overview.
Public Detail Page
On the published content's Discovery detail page, the version history is accessible to both you and your subscribers. Subscribers see the same list of versions, changelogs, and release notes — they just don't get the rollback and snapshot actions (those are owner-only).
The Version History Panel
The panel lists every version, newest first.
Version List
Each row in the list shows:
| Element | What it shows |
|---|---|
| Version number | v1, v2, v3... Increments with each publish. |
| Version title | The short label you gave this version ("Big Personality Overhaul," "Fixed Greeting Bug"). Blank if you skipped it at publish time. |
| Published date | When the publish happened. |
| Snapshot marker | If this row is a named manual snapshot rather than a publish, it's labeled as such. |
| Stable marker | If you've marked this version as the stable canonical fallback, it gets a "Stable" badge. |
| Current marker | The version subscribers are currently on gets a "Latest" badge. |
Per-Version Actions (Owner Only)
Expanding a version row reveals a set of actions you can take on that version:
| Action | What it does |
|---|---|
| View | Opens a read-only preview of what the content looked like at that version. |
| Diff against current | Opens the diff viewer comparing this version against your current live draft. |
| Diff against previous | Compares this version against the version immediately before it. |
| Roll Back to This | Creates a new version whose content is copied from this snapshot (see Rollback). |
| Publish From This | Skip the current draft and publish this older version directly — useful when you drafted a v8 but want to ship the v7 state. |
| Mark as Stable | Pins this version as the stable canonical fallback (see Stable Versions). |
Diffing
The diff viewer is your primary tool for understanding what changed between any two versions. You can access it from the Version History panel or from the Publish Version modal (which shows a diff of your pending draft against the last-published snapshot).
Diff Modes
| Mode | Layout |
|---|---|
| Side-by-side | Two columns — older version on the left, newer on the right. Changed passages highlighted in red (removed) and green (added). Default on desktop. |
| Unified | Single column showing removed and added lines interleaved, with context lines in between. Better for long-form field changes on narrow screens. |
Diff Granularity by Field Type
Different fields render differently in the diff view:
| Field Type | Diff Rendering |
|---|---|
| Long-form prose (description, personality, scenario, first message, example dialogue, content body) | Word-level diff showing exact deletions and insertions. Unchanged passages are shown dimmed with a "..." collapse for long unchanged stretches. |
| Scalar settings (temperature, top-p, max tokens, etc.) | A simple value comparison: "0.7 → 0.85" |
| Toggle/flag fields | "Enabled → Disabled" or vice versa |
| Ordered lists (prompt stack, lorebook entry order) | Reorders shown as items moving with arrows; additions shown as green rows; removals as red rows |
| Individual items (lorebook entries, prompt items, regex rules) | Each changed item shows its own mini-diff |
The diff viewer's scope matches what was captured in the snapshot. Fields that weren't changed between the two versions are collapsed by default and expandable if you want to confirm they're identical.
Comparing Across More Than Two Versions
From the Version History panel, you can set both the "from" and "to" version manually — click any version's Diff against current or Diff against previous to start, then use the version selectors at the top of the diff view to switch to any two versions. This lets you compare v2 against v7 directly, for example.
Rollback
Rolling back doesn't rewind time — it creates a new version whose content is identical to an older snapshot, and records in the metadata that this was a rollback.
How Rollback Works
- In the Version History panel, find the version you want to return to.
- Click Roll Back to This.
- A confirmation dialog shows you what you're rolling back from (the current draft) and back to (the older version). It notes that this will create a new version.
- Confirm. The standalone editor now shows the content as it was at the rolled-back version. The content is in a pending-publish state — your subscribers haven't seen the rollback yet.
- Open the Publish Version modal and publish. The changelog will show something like "Rolled back to v4" with any specific field changes visible in the diff.
Why It Creates a New Version
Version history is append-only on purpose. Snapshots are never modified or deleted — they're permanent records. Rolling back is recorded as "v9 = rollback of v4," not "delete v5–v8." This means you can always see the full edit history, including the detour that didn't work out.
Subscribers see the rollback as a new version in their history, with the same "Update available" notification as any other publish. They can look at the changelog to understand it was a revert.
Publish From This Version
A lighter alternative to rollback is Publish From This: it creates a new version from an older snapshot's content without touching your current draft. Your draft stays exactly as you left it; a new version is published from the chosen older state. Useful when you want to hotfix subscribers to an older known-good version while continuing to draft a bigger future release.
Snapshots
A snapshot is a named restore point you create manually, without publishing. Snapshots appear in the Version History panel alongside regular published versions but are labeled differently — they're visible only to you, not to subscribers.
When to Use Snapshots
- Before making a large structural change you're not sure about ("Snapshot: Before personality rewrite")
- At a stable point in a long drafting session before you keep going
- When you want a named reference point but aren't ready to publish
Creating a Snapshot
In the Version History panel, click the Snapshot button. You'll be asked for a name (required — snapshots without names aren't very useful). The snapshot is created immediately from the current draft state.
Using Snapshots
From a snapshot row in the Version History panel, you can:
- View — preview the content at the snapshot moment
- Diff against current — see what's changed since you snapshotted
- Roll Back to This — same as rolling back to a published version (creates a new published version if you confirm and publish)
- Delete snapshot — remove it from the list (snapshots, unlike published versions, can be deleted)
Snapshots don't count toward your version number sequence — publishing after taking two snapshots still publishes as the next incremental version number.
Stable Versions
You can mark any published version as stable — a designation that means "this is the canonical, long-term-supported version."
What Stable Does
- Discovery cards default to the stable version for display purposes. If your current live version is v9 but v7 is marked stable, visitors browsing Discovery see the stable version's content in the detail page preview. (Subscribers with auto-update still get your latest — stable is a display preference, not a subscriber-side override.)
- Stable appears in the version history with a distinct badge, so subscribers and visitors can easily identify it.
- Useful for longer-running projects where you want to signal "this is the polished, tested state" while v8 and v9 are experimental publishes being refined.
Changing the Stable Version
You can mark any published version as stable at any time. Marking a new one removes the stable designation from the previous one — there can only be one stable version at a time. You can also clear the stable flag entirely, returning to the default behavior of showing the latest version.
Forks and Versions
When someone forks your character, their fork pins to a specific snapshot — whatever version was current at the time they forked. From that moment, the fork is independent.
Fork-Side Version Tracking
The forker's copy records:
- Which version of your character they forked from
- When they forked
- Your character's name at the time of fork
If you later publish v7, v8, v9 to your character, the fork owner doesn't automatically receive those changes. Their fork stays at the version they started from.
Update Notifications for Forks
When you publish a new version, fork owners see a notification on their Library card: "Upstream has new changes" with a link to view diff. The diff shows exactly what changed in your latest version compared to the version they forked from.
Sync From Upstream
The fork owner can choose to pull your changes via the Sync from upstream flow. This is a 3-way merge, not a silent overwrite:
- The merge compares three states: the version the fork was based on, the fork owner's current content, and your latest version.
- Fields where only you changed something are auto-merged into the fork.
- Fields where both you and the fork owner made changes are surfaced as conflicts — the fork owner sees both versions side by side and picks which to keep (or merges them manually).
- The fork owner confirms the merge and the result becomes a new draft on their fork.
This means fork owners are never forced to accept your changes, and they never silently lose their own edits when syncing.
Repertoire Subscribers Are Different From Fork Owners
Subscribers (Repertoire) are not the same as fork owners. Subscribers receive your versions automatically or see an update badge. Fork owners have an independent copy and must actively choose to sync. This distinction is covered in depth in Publishing & Sharing.
Version History Visibility
| Who can see it | What they see |
|---|---|
| Owner (you) | Full version history, all actions (view, diff, rollback, publish from, snapshot, mark stable) |
| Subscribers | Full list of published versions, changelogs, release notes, diff between any two versions. No rollback or snapshot actions. |
| Public visitors (not subscribed) | The version history tab on the detail page shows published versions with changelogs and release notes. Diff is available. No actions. |
| Fork owners | Their fork's own version history, plus the upstream notification badge. The upstream version history is viewable on the original's detail page. |
Version History on PlotLight
Subscribers and visitors can also browse version history from the character's, preset's, or lorebook's detail page on PlotLight. The same version list and changelog view are available there — visitors see what changed between versions, read the release notes the creator wrote, and understand what the "Stable" version represents.
See Versioning & Lineage on PlotLight for the visitor-side perspective — how the lineage chain displays across fork levels, how "update available" notifications appear for subscribers, and what the stable version marker means on a Discovery card.
Tips & Best Practices
Publish in meaningful batches. Each publish notifies your subscribers. Three publishes in a day for minor tweaks is noisy. Hold edits and publish once with a complete changelog — your subscribers will read it more carefully when it's not constant.
Use the version title every time. "v4" means nothing; "v4 — Personality Rewrite + New Battle Alt" is scannable in a second. Subscribers reading version history at a glance will appreciate it.
Write release notes for big changes. Subscribers who haven't opened the content recently benefit from understanding why you changed what you changed. "Restructured the description to reduce token cost" or "Replaced three prompts with a single cleaner one" is genuinely useful context.
Snapshot before experiments. If you're about to try a major structural change in the editor, snapshot first. It costs nothing and gives you an instant restore point if the experiment doesn't work out.
Mark a stable version once you have one. If your content goes through rapid iteration early on, mark a version stable once you're happy with the core behavior. Discovery visitors and long-term subscribers see the stable version as the reference point.
Check for upstream updates on your forks periodically. If you've forked something you rely on, check the upstream regularly — the creator may have fixed bugs or added features you'd want. The diff view makes it easy to see exactly what changed before you decide whether to sync.
Don't over-use rollback for small fixes. If you published v4 and immediately spotted a typo, just fix it and publish v5. Rollback is for when v4 was a wrong direction — a personality rewrite that didn't land, a structural change that broke things. Rollback for a typo is more notification noise than it's worth.
Use "Publish From This" for hotfixes. If you're deep in drafting v8 and your subscribers hit a bug in v7, use "Publish From This" on a known-good older version rather than publishing your half-finished v8 draft. Your draft stays untouched.