@v1 is the release channel for organizer forks. A fork's CI does:
uses: OpenTechEvents/ote-tools/.github/workflows/validate.yml@v1
GitHub resolves that tag when the fork's CI runs, so the fork executes whatever commit @v1 points at. Moving the tag deploys to every fork at once, without any fork changing a line.
The tag still points at 305eda2 (2026-07-16) — 164 commits behind main. Every fork is running July's tools, not the OTE Spec 0.4.0 ones.
What is already answered
The 0.4.0 spec migration asked whether moving the tag breaks forks. On the schema delta alone, it does not, and this was checked rather than assumed:
- Forks never write
specVersion themselves. buildFeed() generates it (packages/build-feed/src/index.ts), taking it from @opentechevents/validate. It is not a field of ote.config.json, and events inherit it. So the one rule that got stricter in 0.4.0 — the const "0.4.0" — is applied to a value the tools write, never to one an organizer wrote. No migration step is needed on the organizer's side.
- Everything else in v0.3 → v0.4 is a relaxation.
format: uri → iri on every URL field, image ^https:// → ^https?:// on both image shapes. No enum member was removed anywhere, so no license id that validated before stops validating.
What is not answered, and blocks the move
That analysis covers the spec and nothing else. Six weeks of commits also touched the surface a fork actually consumes. Before the tag moves, one of:
Then move @v1 (and v1.0.0, or decide whether that pinned tag should stay where it is).
Context and the reasoning above live in HANDOFF.md § "Moving the @v1 tag".
@v1is the release channel for organizer forks. A fork's CI does:GitHub resolves that tag when the fork's CI runs, so the fork executes whatever commit
@v1points at. Moving the tag deploys to every fork at once, without any fork changing a line.The tag still points at
305eda2(2026-07-16) — 164 commits behindmain. Every fork is running July's tools, not the OTE Spec 0.4.0 ones.What is already answered
The 0.4.0 spec migration asked whether moving the tag breaks forks. On the schema delta alone, it does not, and this was checked rather than assumed:
specVersionthemselves.buildFeed()generates it (packages/build-feed/src/index.ts), taking it from@opentechevents/validate. It is not a field ofote.config.json, and events inherit it. So the one rule that got stricter in 0.4.0 — theconst "0.4.0"— is applied to a value the tools write, never to one an organizer wrote. No migration step is needed on the organizer's side.format: uri→irion every URL field, image^https://→^https?://on both image shapes. No enum member was removed anywhere, so no license id that validated before stops validating.What is not answered, and blocks the move
That analysis covers the spec and nothing else. Six weeks of commits also touched the surface a fork actually consumes. Before the tag moves, one of:
git diff 305eda2..mainover the fork-visible surface —packages/build-feed(config fields, CLI flags, exit codes, error text),.github/workflows/validate.yml,.github/workflows/build-pages.yml— and list anything that would turn a green fork red.uses:at@mainand run its CI, which is whatCONTRIBUTING.mdalready prescribes for reusable-workflow changes.Then move
@v1(andv1.0.0, or decide whether that pinned tag should stay where it is).Context and the reasoning above live in
HANDOFF.md§ "Moving the@v1tag".