release-changelog

Topics in the source

• Release Changelog Skill
• Versioning Model
• Channel Process — Source Commit and File Location
• Step 0 — Idempotency Check
• Step 1 — Determine the Stable Range
• Step 2 — Gather the Raw Inputs
• Step 3 — Detect Breaking Changes
• Step 4 — Categorize for Users

Generate the user-facing changelog for the stable Paperclip release. Paperclip uses calendar versioning (calver): Stable releases: YYYY.MDD.P (e.g. 2026.318.0) Canary releases: YYYY.MDD.P-canary.N (e.g. 2026.318.1-canary.0) Git tags: vYYYY.MDD.P for stable, canary/vYYYY.MDD.P-canary.N for canary There are no major/minor/patch bumps. The stable version is derived from the intended release date (UTC) plus the next same-day stable patch slot. Output: releases/vYYYY.MDD.P.md a release Case, upserted by (caseType, key) when Cases are enabled, with a body document revision containing the changelog body Important rules: even if there are canary releases such as 2026.318.1-canary.0, the changelog file stays releases/v2026.318.1.md do not derive versions from semver bump types do not create canary changelog files Stables promote a soaked beta, so the changelog describes the beta's source commit, not the tip of master: The release source is the commit the newest beta/v tag points at ({beta-src} below). Resolve it with: Commits on master after {beta-src} ship in the next release. Never include them; they are input for a "what's next" section, not the changelog. During the soak, the file lives

This is an excerpt. Refer to the complete source and its current requirements.