release

name	release
description	Release ovenplayer to npm — confirm the version, verify the committed dist/ bundle is current, write the release notes, and create the GitHub Release that triggers the npm publish.

Release ovenplayer to npm.

The publish itself runs in CI: creating the GitHub Release fires .github/workflows/publish.yml, which builds and publishes through npm trusted publishing (OIDC). This skill covers everything up to that point. Nothing reaches npm until the release is created, so the release creation is the point of no return — get explicit confirmation there.

1. Preflight

• git status --short and git log --oneline -10. Work from master, with a clean tree, synced with origin (git fetch && git status -sb). Surface anything unexpected — stray modified files, unpushed commits — and ask how to proceed before continuing.
• Establish the baseline with gh release list --limit 3 and npm view ovenplayer version. Do not use git describe for this: some tags in this repo do not sit on master, so it reports the wrong baseline.

2. Confirm the version

• This repo bumps package.json inside the feature commit rather than in a separate release commit, so the version is often already ahead of npm. Compare package.json against the published version first — a bump may not be needed.
• List the commits since the last release, group them into features / fixes / chores, and propose the version from that.
• Show the published version, the version in package.json, the proposal, and the commit list. Ask the user to confirm. Never pick the version silently.

3. Verify dist/ is final

dist/ is committed to the repo and served to jsdelivr consumers, and webpack inlines the package.json version into the bundle as __VERSION__ (webpack.config.js:86). A version bump therefore invalidates the committed bundle.

• Run npm run build, then git status --short dist/.
  • Clean → the committed bundle matches src/ at this version. Say so.
  • Dirty → the committed bundle was stale. Commit the rebuild before tagging (chore: rebuild the bundle, or folded into the version-bump commit).
• Confirm the version embedded in the bundle is the version being released: grep -o '0\.[0-9]*\.[0-9]*' dist/ovenplayer.js | sort -u.

4. Bump, if step 2 called for one

Update the version in package.json and package-lock.json, rebuild so dist/ carries the new __VERSION__, and commit them together. Match the commit style in git log. Push before tagging.

5. Write the release notes

• Read the previous two or three releases (gh release view <tag>). They are hand-written and feature-first: what changed for the user, with code samples for new options. They are not a commit dump. Match that.
• Draft from the actual diff since the last release, not from commit subjects alone. Show the draft and get the user's approval on it.

6. Create the release

• State plainly that this publishes to npm and that a published version cannot be unpublished or replaced. Get an explicit yes.
• gh release create v<version> --target master --title "v<version>" --notes-file <file> (the tag must be v<version> — CI checks it against package.json).
• Watch the result: gh run list --workflow=publish.yml --limit 1, then gh run watch <id>, and confirm with npm view ovenplayer version.
• If the run fails before the publish step, fix the cause and re-run the workflow. If the version already landed on npm, do not attempt to republish it — the next release needs a new version.