migrate
Move a root — its blueprints and top-level docs — from one version of the standard to another.
Migrations are non-sequential
Section titled “Migrations are non-sequential”The part that surprises people, and a deliberate design choice.
It goes directly from any source version to any target, by diffing the two
frozen snapshots in the standard’s versions/ folder. v1.0.0 straight to
v4.4.2 is one hop, not six. There’s no chain of upgrades to run in order, and
no version you have to stop at on the way.
That works because at tag time EIDOS.md is copied as-is into versions/ under
its full semver name, so any two releases can be diffed against each other.
What it touches
Section titled “What it touches”It rewrites the ### Eidos Core block in your Framework.md and bumps
eidos_version.
How it works
Section titled “How it works”It facilitates rather than bulldozes. A migration touches real content in real blueprints, so it surfaces what it intends to change before changing it.
Where the migration is a judgement call rather than a mechanical rewrite — the 4.3.2 → 4.4.0 hop asks you to record the naming convention your files already use — it reads the answer off the tree, states what it found, and asks you to confirm before writing it down.
It carries the version history
Section titled “It carries the version history”One of three skills shipping a committed copy of part of the standard — here the
frozen versions/ snapshots, so it can diff any two releases wherever it’s
installed.
Why →
Related
Section titled “Related”- Versioning — the two version numbers, and the current hop.