Repository navigation
feat(publish): library generations, so a new world never replaces the library older clients read - #337
Merged
Conversation
… library older clients read (#333) A publisher repository held one library at its root. Publishing the rebuilt world over it would hand pre-0.5 clients night-lit scenery they cannot use. Repository format 2.0.0 holds library generations: each world in its own folder, v1/, v2/, with its index, region_metadata.json, coverage map, packages/ and dist/. The marker records the current generation ("current v2"); every path resolves in it, and --library <gen> runs one command in another. The generation versions a library's contents; the index format is unchanged. staging/ stays at the root, a work area shared by every generation. The root library of a 1.x repository is frozen for clients from before generations: no 2.0.0 operation writes it, and Repository::open refuses a 1.x repository with UpgradeRequired, so no other command can touch one. New commands: - upgrade --root-as v1: copies the root index, metadata and coverage into v1/, moves in the working folders the index lists, reports the rest, makes v1 current. The root files stay byte for byte. - library list | new <gen> | use <gen> | import <gen> --from <dir>. Both upgrade and import plan before they change anything, so --dry-run and a real run agree, and refuse to move onto an existing folder. Rewriting the marker replaces the header lines only and keeps the [config] section, so the archive part size survives. The service reopens repositories at the same generation, so a command run with --library cannot fall back to the current one partway, and coverage reads the generation's packages and region metadata. Verified on a fresh clone of xearthlayer-regional-scenery, with sample working folders from both worlds: upgrade --root-as v1, then library import v2 from the staging branch's files, then library use v2. The root files and their v1/ copies hash identical to before, v2/ matches staging, the marker keeps part_size = 1G, each working folder lands in the generation that lists it, git would add only the eight library files, and a 1.0.0 repository is refused with the upgrade command. Docs: the publishing guide gains Library Generations; the publisher design doc and the world rebuild runbook describe the layout, the promotion procedure and that the old world is frozen, not retired. Closes #333
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A publisher repository held one library at its root, so publishing the rebuilt world over it would hand pre-0.5 clients night-lit scenery they cannot use.
Repository format 2.0.0 holds library generations: each world in its own folder (
v1/,v2/) with its index,region_metadata.json, coverage map,packages/anddist/. The marker records the current generation, and--library <gen>runs one command in another. The root library of a 1.x repository is frozen: nothing writes it, and a 1.x repository is refused untilupgrade --root-as v1. New commands:upgrade,library list | new | use | import.Verification
[config]survives marker rewrites; a deletion after upgrade changes the generation and never the root.upgrade --root-as v1,library import v2from the staging branch's files,library use v2. Root files and theirv1/copies hash identical,v2/matches staging,part_size = 1Gkept, each folder lands in the generation that lists it, git adds only the eight library files, andstatus/validateread the right generation.Closes #333