Repository navigation
fix: judge feeds by the spec version they declare, not 0.3.0 only - #12
Merged
Merged
Conversation
The reader decided whether a document was OTE with `specVersion === '0.3.0'`, so three of the four registered feeds — eventos.wiki and Sarao (0.4.0) and CoruñaJUG (0.5.0) — could not be opened, and the failure was silent: the document downloaded fine and was simply not recognised. The same check ran over the IndexedDB cache, so those feeds were also evicted from the offline cache on every start. A document is now OTE because of its shape — a declared specVersion plus events[] — and the version it declares decides which rules apply to it, never whether it is OTE. Across the four live feeds that moves the reader from 25 events to 701. The support window is the last three minors, computed from the published list rather than written out, so a spec release moves it by itself, and classification is by minor so a patch inside a supported minor is supported before this build has heard of it. Versions outside the window, newer than known, or unpublished are notes next to the events and in the sidebar — never a refusal, and never a reproach: running last season's release is a legitimate choice. No dependency on @opentechevents/validate, deliberately. It reports an out-of-window or unpublished version as an error, so gating on it would make the 0.3.0 feed that works today unopenable and would break every feed again at 0.7.0 — this bug, reintroduced. What the reader needs is the policy, not 3.7 MB of compiled schemas in a no-build PWA, so the policy is mirrored with the same vocabulary and `npm run check` now fails when it drifts from the registry or the published event schema. Also adds `contributing` to the fields an event inherits from its feed, completing the set the event schema marks with x-inheritsFrom since 0.5. Closes #11 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Fixes #11. Supersedes #10, closed as a duplicate.
The bug
isOteFeed/isOteEventtestedspecVersion === '0.3.0', which made theversion a document declares decide whether it was OTE at all. Against the live
registry today:
specVersion25 events before, 701 after, driven in a browser against the four real feeds.
The only feed that opened was the one outside the support window.
hydrateFeedCache()ran the same check, so those feeds were also evicted fromthe IndexedDB cache on every start.
What changed
A feed is a feed because it declares a
specVersionand carriesevents[].PUBLISHED_SPEC_VERSIONS,so a spec release moves it by itself. Appending a version there is the only
edit a release needs. Classification is by minor, so 0.4.1 is as supported
as 0.4.0 before this build has heard of it.
feed and stays quiet on aggregate screens; out-of-window, newer-than-known and
unpublished are flagged in the sidebar too. Nothing stops a feed from being
read and no message asks the publisher for anything.
contributinginherits feed→event, completing the five fields the eventschema marks with
x-inheritsFromsince 0.5.npm run checknow reads the npm registry and the published event schemaand fails when the mirrored version list or the inheritance list has drifted.
Why no
@opentechevents/validateDecided before writing code, since it conditions everything else.
The decisive argument is semantics, not size: the reader must be more tolerant
than a validator.
validateDocumentreports an out-of-window or unpublishedversion as an
error. Gating onreport.validwould make Community Builders'0.3.0 feed unopenable — it works today — and would break every feed again at
0.7.0, which is this issue's bug with a better pedigree. A schema failure in one
event would also invalidate a whole feed where the right behaviour is to show
the other 484.
Size confirms rather than decides: ESM-only with per-version dynamic
import()aimed at a bundler, ~3.7 MB of compiled validators, against a no-build PWA whose
whole
app.jsis 86 kB. Vendoring means megabytes in the repo and the SWprecache; a CDN means an offline-first reader depending on a third party to
decide whether it can open a file.
So the policy is mirrored, not the schemas — same vocabulary (
current/outdated/out-of-window), plusfuturefor a version newer than this buildknows, which a validator has nothing to check against but a reader can show and
label. Drift is covered by
npm run check.Verification
single-feed view shows the full sentence and aggregate views stay quiet about
merely-outdated feeds.
banana, missing, andrecognition/inheritance cases.
npm run checkgreen.Follow-ups that are not this PR are in #13.
🤖 Generated with Claude Code