YESS
HandbookLearning56

Content versioning.

A teacher rewrites a lesson the night before class, then realises last week's version was better. Without a safety net, that older wording is gone. YESS content versioning is the net: a per-course ledger where a teacher saves a titled snapshot of lesson content with a note on what changed, browses the history newest-first, and rolls back to any earlier version in one click. This handbook is precise about the shape of it — a real, working version chain with a true rollback, kept honestly as its own ledger rather than automatic change-tracking of every live edit.

  • 50versions kept / course
  • 1click rollback
  • 5chapters
  • ≈8 minto read

Prologue

A version ledger, filled by hand#

One thing to name cleanly before we open a screen, because it changes how you use the feature. This is not silent change-tracking that snapshots a lesson every time someone edits it. It is a version ledger a teacher fills deliberately: you open the versioning screen, paste or type the content you want to keep, give it a title and a note on what changed, and save a version. The value is the rollback and the history — a dependable record you chose to keep — not automatic surveillance of every keystroke.

The ledger lives at /dashboard/content-versioning, scoped per course. Each course has its own independent chain of versions, numbered in order, with exactly one marked as the current one. Everything in this book is about that chain: how a version is saved, how you roll back to an earlier one, and — just as important — what the feature does not yet do.

Keep the versions worth keeping, and never lose the one that was better — a way back is always one click away.

Chapter one

Saving a version#

Open /dashboard/content-versioning and pick a course from the selector — nothing loads until you choose one. Click New Version and fill three fields:

Three fields on a version

  1. 1

    Title

    A name for this version — 'Term 2 rewrite', 'Fixed the worked example'. It is what you scan the history by later.

  2. 2

    Content

    The lesson content itself, entered as text (Markdown is supported). This is the snapshot the version preserves — you paste or type the material you want kept at this point in time.

  3. 3

    Change summary

    A one-line note on what changed since the last version — the message that makes the history readable, the way a commit message makes a codebase readable.

Save, and YESS does the bookkeeping: it stamps the new version with the next number in the course's chain, clears the current marker from whatever version held it, and marks this new one current. It records who saved it and when. The version drops to the top of the history list, badged Current, with your change summary beside it and a short preview of the content.

Designed product mock — the version ledger for a course: the New Version dialog (title, content, change summary) beside a newest-first history, the top card badged Current.

Chapter two

Rolling back#

This is the feature that earns the module its name, and it is real and fully wired. In the history list, every version that is not the current one carries a Rollback button. Click it, and a confirmation appears: "Rollback to version N? This will make it the current version. The previous current version stays in history."

Confirm, and YESS moves the current marker to that earlier version. Nothing is deleted and nothing is copied forward — rollback is a flag flip, not a rewrite. The version you rolled back to becomes current; the one that was current a moment ago stays in the history, right where it was, so you can roll forward again just as easily. The chain is never destroyed by a rollback; only the pointer to "which one is live" moves.

Chapter three

What it does not do#

Honesty about the edges keeps a school from expecting a Google-Docs revision history it will not find here. Three things to know:

  • It does not auto-capture live edits. Editing a lesson elsewhere in the LMS does not create a version. The content in a version is the text you type into this screen's dialog — a deliberate snapshot, not a mirror of the course's live body.
  • There is no side-by-side diff. The screen previews each version's content and lets you roll back, but it does not yet show two versions line-by-line with the changes highlighted. You compare by reading the previews and the change summaries.
  • There is no draft / published / archived lifecycle. A version is simply current or not, and every saved version reads as published. There is no held-back draft state and no archive — the workflow is "save a version, make one current", nothing more.

None of this breaks the core promise — save versions, roll back safely — it just sizes it. The richer comparison and true content-linkage are in the roadmap below.

Chapter four

What this ledger does well#

Four things done right

  1. 1

    A real, safe rollback

    Rollback is a fully implemented pointer move, not a promise — it makes any earlier version current while leaving the whole chain intact, so you can move the 'live' marker back and forth without ever losing a version.

  2. 2

    One current version, always

    Saving a version clears the current marker from the old one and sets it on the new — the chain is numbered and there is exactly one current version at any time, so there is never ambiguity about which content is live.

  3. 3

    A readable history

    Every version carries a title, a change summary, and who saved it and when — so the history reads like a changelog, not an opaque pile of snapshots.

  4. 4

    Bounded by design

    The newest fifty versions per course are kept and older ones pruned automatically, so the ledger stays fast and the versions you would actually roll back to are always at hand.

Planned & honest gaps

What is still to come#

The save-and-rollback core is real and dependable. The polish — a diff, a link to live content, a proper draft state — is honestly not there yet. The straight list:

Five honest gaps

  1. 1

    Side-by-side comparison

    The building block for a version diff exists in the database, but no screen renders two versions against each other with changes highlighted. A visual compare view is planned.

  2. 2

    Auto-snapshot on edit

    Versions are saved by hand today, decoupled from the course's live lesson body. Automatically capturing a version when lesson content is edited elsewhere in the LMS is planned.

  3. 3

    A draft / archive lifecycle

    Every version reads as published and current-or-not; there is no held-back draft or archived state. A publish-when-ready workflow is planned.

  4. 4

    Rich-content versioning

    A version is text with Markdown; the schema allows HTML and rich text, but the screen only takes plain content and does not version embedded images or files. Versioning rich content and its assets together is planned.

  5. 5

    Restore-forward as a new version

    Rollback moves the current pointer rather than writing a new version from an old one. An option to 'restore this version as a new latest version' is planned for teams that prefer an append-only chain.

Adjacent modules

Where versioning connects#

Versioning sits under a course's content, alongside the notebooks students annotate it in and the coverage the logbook tracks.

Tutorial

Do it step by step#

Keep a safety net under a lesson you are about to rework — save the good version first, then roll back if the rewrite goes wrong. Four steps, all the teacher's.

  1. 1

    Pick the course

    Open /dashboard/content-versioning and choose the course from the selector. Its version history loads, newest first, with the current version badged at the top.

    Each course keeps its own independent version chain — nothing loads until you pick one.

  2. 2

    Save the version worth keeping

    Before a big rewrite, click New Version, give it a title, paste the content as it stands, and add a change summary. Save — it becomes the current version and drops to the top of the history.

    The change summary is what makes the history readable later — treat it like a commit message.

  3. 3

    Rework freely, saving as you go

    Make your edits and save them as new versions whenever you reach a point worth keeping. The ledger keeps the newest fifty per course, so save generously — old ones prune themselves.
  4. 4

    Roll back if it goes wrong

    If the rewrite does not work out, find the earlier version in the history and click Rollback. Confirm, and it becomes current again — the newer version stays in history, so you can always roll forward.

    Rollback is a safe pointer move, never a delete — nothing in the chain is lost when you roll back.

A snapshot saved on purpose, a history you can read, and a one-click way back — a teacher can rework a lesson without ever fearing the undo.