An EPUB is not always built just once. Fix a typo, build. Add a chapter, build. Which makes "which one is current?" a bigger problem than the building itself. If an older build is mistaken for the latest one, readers can receive an earlier chapter order or stale contents and struggle to find the chapter they expected.
The answer is straightforward. Treat working EPUBs as regenerable outputs and declare that the manuscript and settings are the master. This article combines the steps for rebuilding an EPUB with contents and a cover with a way to keep track of the latest build. Detailed metadata entry and store submission are covered separately.
Rebuilding many times is normal
An EPUB is commonly rebuilt at several points between finishing a draft and publishing, for example:
- Build one: get it into shape and check the contents and cover
- Builds two to five: typo fixes
- Build six: reordering chapters
- Build seven: correcting the publication date
- After publication: responding to reader feedback
The count varies by project, but every export adds another output to manage.
The usual ways of managing it
Most people add their own numbering or dates to the file name — book_v2.epub, book_0905.epub.
The other approach is overwriting: only the latest matters.
Unmanaged hand-numbering can drift
When no separate build record is kept, manually assigned numbers can stop matching the order you built in.
You rebuild and forget to increment; or you increment without any change. A few days later, telling book_v3 from book_v4 requires checking timestamps anyway.
Overwriting without retaining a comparison build removes that earlier output as a fallback. When you decide the previous version was better, there is nothing to compare against. Reordering the contents and then wishing you had not is a real situation.
Version control or an explicit build ledger can preserve which manuscript produced which EPUB even when names are numbered by hand or an output is overwritten. The risky case is relying on filenames and modification dates without that provenance record.
rune Studio puts a timestamp in the output name
Files exported from rune Studio are named with a timestamp.
I verified this by driving the development build from the command line. Exporting with a chosen output name produced a file with that name followed by a timestamp. Exporting with a fixed clock value put exactly that value in the name.
The timestamp in the filename provides evidence for build order. It can replace manual numbering as the first new-versus-old check. Because the name changes on each ordinary export, a retained previous file is less likely to be overwritten by accident and can sit beside the new build.
Fix the date and time when you need a comparison
The awkward case when comparing is "the contents should be identical but the files differ", because the build time is recorded inside.
rune Studio can export with a fixed date and time. I verified that two exports can be made with the same specified time. This removes the output time itself as a source of difference when comparing builds. It does not prove that every other input and setting is identical; compare with the manuscript, cover, chapter order, and metadata held constant too.
Put contents and cover in the rebuild record
When rebuilding an EPUB with contents and a cover, include both in the same record as the body. This article does not claim an unregistered rune Studio generation rule; it limits the workflow to comparing the same inputs with the resulting EPUB on every rebuild.
- Record the selected manuscripts and chapter order
- Record the cover image for this build
- Record the headings intended for the contents
- Generate the EPUB
- Confirm cover, contents, and body correspondence in the result
Using the same five checks after every revision lets you verify that cover, contents, and body correspond to the recorded inputs. That evidence helps you avoid handing readers a build with an older chapter order or stale contents.
Every build can be checked
rune Studio can inspect the inside of the exported EPUB. Running that inspection on the normal test output returned a valid verdict.
Running it on every rebuild checks the internal items verified in this project: packaged resources, reading order, contents, and leftover notation. The record covers one valid test output; it does not establish detection of every possible fault or any inspection-time guarantee.
The selection and order of manuscripts is remembered
Which files were used, and in what order, is recorded within the workspace. Checking this returned the remembered order and whether each file can still be opened. On a later return, that recorded selection and order can be used as the starting point. The test did not measure a particular retention period.
Fix the storage location in your own process
Choose one folder for working EPUBs and combine it with the timestamped output name. This article does not assert a rune Studio-specific fixed destination; record the selected destination and filename after each generation.
Before clearing old files, decide whether the published build or a comparison build needs to be retained. Being able to regenerate from the manuscript and settings is separate from preserving an output that was actually submitted. Use timestamped names for the current working build, and associate retained builds with their publication date or purpose.
Who this suits, and who is fine without it
It suits anyone who keeps revising after publication. If you bump versions in response to reader feedback, this is exactly the situation it addresses.
If you build once, need no comparison output, and do not expect to regenerate, keeping one output may be enough. If that file is overwritten without a retained comparison build, however, the pre-change output is no longer available for comparison.
Scope note: what was verified is exporting, the file naming, and the inspection. Replacing a published version follows your store's own process.
Summary
- Revisions create multiple builds, so knowing which is current is a real requirement
- Hand-numbering without a build record can drift; overwriting without a retained comparison build removes that fallback
- rune Studio timestamps the output name, so the name provides evidence for build order
- Cover, contents, and body belong in the same rebuild checklist
- Fixing the clock removes the output timestamp as a comparison variable
For a first step, look at the EPUB file names you have now. If the name alone does not tell you which is newest, that is what to fix.
Treat cover, contents, and body as one recorded build, then select the build with the current chapter order. That is how build tracking protects readers from being sent through stale contents.
See the current product scope on the Rune Studio product page.
