Rehearse a Release-Candidate Rollback Before Release Day

A rollback begins before the fault

A release candidate is useful only when a team can say exactly what it contains and how to return to the last approved object. Give each candidate a version label, date, source revision, output filenames, and a short change list. Keep the approved predecessor available. This is different from archiving source files: the rehearsal concerns the outward package and the decision path if it must be replaced.

Choose a reversible test

Do not simulate a public takedown without authority. Instead, take a local or staging candidate and practice selecting the prior approved package, verifying its checksum or source revision, restoring it in the same preview path, and confirming that its title page, metadata, and sample link agree. The exercise exposes whether a folder called ‘final’ is actually a release record or merely a hopeful label.

Write the trigger plainly

List conditions that require a stop: corrupted file, wrong interior, broken purchase or download link, material attribution error, or an incorrect public claim. ‘Someone dislikes the cover’ is not the same class of trigger. For each, name who can pause release, who decides replacement, which reader-facing notice is permitted, and what evidence is needed. A calm trigger table prevents an urgent chat from becoming the only record.

Preserve versions; do not rewrite them

If Git is part of the production record, use an annotated tag or equivalent immutable reference for the approved candidate. Git’s documentation warns that changing a tag already shared with others creates ambiguity; a new, clearly named corrective release is safer than silently moving an old name. GitHub likewise treats releases as tag-based points in history and supports drafts before publication. These are useful analogies even when the deliverable is a book file, not software.

End with a reconciliation

After the rehearsal, compare the restored candidate with its release sheet: cover, interior version, ISBN or product identifier where applicable, accessibility metadata, price fields if in scope, and linked sample. Record the steps taken and any failures found; if none were observed, say so. Do not claim the rehearsal proves an external retailer will update instantly or that every cached copy disappears. Its narrow achievement is preparedness: the team knows which version is authoritative and how to make that visible.

Repeat the rehearsal after a meaningful workflow change: a new distributor, conversion tool, storage location, or person with approval authority. Small changes often invalidate an old runbook without anyone noticing. Keep the rehearsal scoped to systems the team controls, and escalate external actions to the authorized owner. The point is not technical drama; it is a calm path from an identified defect to a truthful, verified replacement.