Skip to content

docs: record the two release chores nothing checks for you #16

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
hhkaos merged 1 commit into from
Nov 5, 2026
Merged

docs: record the two release chores nothing checks for you #16

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions CLAUDE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,3 +19,39 @@ update these together before considering the task done:

Internal/invisible changes (refactors, tooling, comments) don't need a
version bump or changelog entry.

## When the OTE spec publishes a new version

The support window is the last three minors, computed — not listed — so
one edit moves it:

1. Append the new version to `PUBLISHED_SPEC_VERSIONS` in `app.js`. The
window, the latest version and every message derive from it.
2. Update the **OTE spec badge range** at the top of `README.md` (e.g.
`v0.4 – v0.6`). This is the one thing nothing checks for you — see
below.

`npm run check` reads the npm registry and the published event schema and
fails when `PUBLISHED_SPEC_VERSIONS` or `INHERITED_FEED_FIELDS` in
`app.js` have drifted from them. It does **not** look at the README, so
the badge goes stale silently.

A document is always judged against the version it *declares*, never
against the latest one, and a feed outside the window still opens — being
on an older release is a notice, never a defect, and no message blames
the publisher. Deliberately no dependency on `@opentechevents/validate`:
a reader must be more tolerant than a validator. The reasoning is in
README under "OTE spec version support"; don't re-litigate it without
reading that first.

## When `<ote-events>` publishes a new version

The widget is pinned by URL in `index.html` (`/embed/vX.Y.Z/`) and is a
separate version line from the OTE spec — the widget's own
`oteSpecVersion` says which spec release it targets, and it lags. Before
bumping, check the widget's **source** for the attributes and properties
this app sets (`layout`, `group-events`, `fields-preview`,
`fields-detail`, `show-past`, `sort`, `event-actions`, `theme`, and
`events` / `eventActions` / `eventClassName` / `eventBadges`), then
verify in a browser — the reader renders nothing itself, so a widget
regression is invisible to `npm run check`.
11 changes: 11 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,16 @@
# OTE Reader

[![Deploy GitHub Pages](https://github.com/OpenTechEvents/ote-reader/actions/workflows/pages.yml/badge.svg)](https://github.com/OpenTechEvents/ote-reader/actions/workflows/pages.yml)
[![OTE spec](https://img.shields.io/badge/OTE%20spec-v0.4%20%E2%80%93%20v0.6-2563eb)](#ote-spec-version-support)
[![Reader](https://img.shields.io/badge/reader-opentechevents.org-2563eb)](https://reader.opentechevents.org)
![PWA](https://img.shields.io/badge/PWA-offline--first-5b21b6)
![Build step](https://img.shields.io/badge/build%20step-none-555555)
![License](https://img.shields.io/badge/license-MIT-339933)

Supported OTE spec minors: **0.4, 0.5, 0.6** — the last three published minors,
computed at runtime from `PUBLISHED_SPEC_VERSIONS` in `app.js`. Feeds outside
that window still open; see [OTE spec version support](#ote-spec-version-support).

Attendee-facing MVP for OpenTechEvents feeds.

The first version is a static PWA that lets people:
Expand Down