D56. Changesets, release PRs and public release records (17 Oct 2026)

Revised on 19 Oct 2026: a core release has one tag, v<version> (the @elabora/* packages are private and not published, so they need no tag of their own), and its checks rerun CI on Linux and Windows only (macOS stays weekly and on demand). The first app release is 0.1.0, called « bêta » in the copy only, on the stable update channel; its Windows build and the first macOS build ship unsigned (signing in the app’s release.config.json), and the next macOS releases are signed and notarized. The release-assets token writes to the assets repository only; a separate token may only dispatch the website’s workflow. The rest of this entry is kept as it was decided.

Core records observable changes as Sampo changesets. Its package versions move together, independently of the course schema version. A release PR contains version bumps, lockfile updates and generated changelogs; merging it runs validation and tags the exact merged sources. Initially publication means GitHub Releases, not npm publication. Sampo is pinned as a development dependency.

Desktop releases pin an exact tested core commit and describe only the newly delivered app/core behavior. One versioned public record supplies English and French app highlights, detailed website notes, and updater metadata. Important features have French text; technical details may fall back to English. App highlights are bundled so that they remain available after updating and offline. First installations establish a baseline without an update announcement.

Application installers are built on hosted Windows and macOS runners only for releases or explicit manual requests. Ordinary app development does not start Windows CI. Signed assets and update metadata are staged together before a draft release becomes public; publication then requests the website refresh. Public assets are separate from private application sources. The agent preparation workflow reports missing setup without inventing credentials or publishing an unreviewed release.

Revisit if: package versions need separate release schedules, npm publication is enabled, or long stabilization periods require maintenance branches.