- Never move an existing release tag.
- Preserve the working commit before structural or data changes.
- Keep
maindeployable. - Verify GitHub Pages after merge.
- A runnable snapshot complements a tag; it does not replace the exact tagged source.
- Documentation milestones do not create or move functional release tags.
- Data migrations must preserve prior datasets and translation variants as recoverable sources.
- Confirm the exact
maincommit. - Confirm the site works at that commit.
- Create a semantic tag and GitHub Release targeting the exact SHA.
- Record the tag, SHA, date, purpose, and limitations in
VERSION.mdandCHANGELOG.md. - Do not retarget the tag later.
The current verified functional checkpoint is:
v23.8.0
24dece593bea679485057d7551a2583f7f1f5acf
The previous checkpoint is v23.7.0. The independently runnable pre-cleanup fallback remains versions/v3.0.0/.
Documentation milestone 23.8.3 establishes the unified product vision and next-stage boundary but does not replace the functional v23.8.0 checkpoint.
A directory under versions/<tag>/ should include:
- runtime HTML and JavaScript;
- active data required by that version;
- manifest, service worker, and icons when PWA behavior is retained;
- relative paths appropriate to the snapshot directory.
Path-only changes needed for subdirectory execution must be documented. Do not backport later features into a released snapshot.
No separate runnable snapshot was added for v23.8.0; the immutable Git tag is the exact source checkpoint.
npm test
node scripts/validate-project.mjs
jq empty data/divinity_code_ru.json
python3 -m http.server 8019Check the current root and every newly added snapshot. Verify database fetches, search, icons, PDFs, manifests, service workers, browser console errors, runtime-version consistency and installed-PWA update behavior.
For v23.8.0, the release workflow checks the exact target SHA, runs tests and validation, verifies package.json, src/version.js and version.json, and creates or verifies the immutable tag before creating the GitHub Release.
Before a future data migration:
- record the active dataset ID, source, language, version, record count and hash;
- preserve the complete previous dataset or translation variant;
- document transformation scripts, rules and manual edits;
- validate IDs, required fields, references and record-count changes;
- create a dedicated data release or restoration reference;
- verify that rollback restores both runtime behavior and the previous dataset.
A new translation must never rely on replacing the only stored copy of the previous translation.
Create a new branch from the stable tag and open a pull request to restore the required files. Do not force-move main and do not delete later history.
Restore the root runtime files from tag v23.8.0 in a new commit, then verify Pages. This preserves a visible audit trail. If the failure is specific to the PWA update and installation flow, use the previous checkpoint v23.7.0. If the failure originates in the earlier modularization, the older v3.6.0 and v3.0.0 checkpoints remain available.
Restore the previously recorded dataset version without deleting the failed candidate. Revert the runtime selector or active-dataset reference in a new commit and retain both variants for audit.
Keep the runnable saved version available:
https://sunpole.github.io/udream/versions/v3.0.0/
After every release, record:
- tag and exact SHA;
- live URL checked;
- checks actually run;
- known limitations;
- rollback target;
- active dataset identity and record count when data changed;
- whether the saved-version launcher was updated.