Immutable. This exact content is served forever at /api/v1/blob/d8d3ea3ddaf608f1.
--- name: release description: Use when bumping the ivue package version, tagging a release, or preparing an npm publish — the repo's versioning/tagging conventions and the gates that must pass before a version is stamped. --- # release — version bump & tag conventions for ivue ## Tag format (the convention) Release tags are **`ivue@X.Y.Z`** — package name, `@`, exact semver. Always annotated: ```bash git tag -a ivue@2.0.0 -m "ivue 2.0.0 — <one-line highlight>" <commit> ``` - Pin the commit explicitly (the `chore(release)` bump commit) so the tag cannot land on an unrelated HEAD. - The history also contains `vX.Y.Z` tags and one stray `vue@0.1.2` typo — leave them alone; `ivue@X.Y.Z` is the one convention to use. ## Version bump 1. **Pick the semver level from the unreleased commits**: any `feat!` / breaking change → major; `feat` → minor; `fix`/`perf`/`refactor`-only → patch. When in doubt, ask the user — never guess a major. 2. **Edit `package.json` `"version"` directly.** Do NOT use `npm version`: it auto-creates a `vX.Y.Z` tag (wrong convention) and runs its own git commit. This repo's lockfile is `yarn.lock` — never generate a root `package-lock.json`. 3. Commit the bump as `chore(release): X.Y.Z`. ## Gates — all must pass BEFORE the bump commit is tagged - `npx vitest run --coverage` → all tests pass, 100% on every metric. - `npm run build` → `gzip -c dist/index.es.js | wc -c` still rounds to the advertised 1.1 kB (≤ ~1,149 B). - Vendored engine synced: `diff lib/Reactive.ts examples/playground/src/ivue.ts` is empty. - If docs changed since the last release: `npm run build:docs` passes. ## What the agent never does - **Never `git push`** — the user pushes, including tags. When they ask, the command is `git push origin main --follow-tags` (`--follow-tags` sends annotated tags on pushed commits; never suggest `--tags`). - **Never `npm publish` / `npm run release`** — publishing is the user's key-turn. `npm run release` = `npm run build && npm publish`; the `prepack` hook fires inside publish and syncs `.claude/skills/ivue/SKILL.md` → `skills/ivue/SKILL.md` into the tarball. Offer `npm pack --dry-run` as a pre-flight instead. ## Release notes — always hand the user paste-ready text After tagging, ALWAYS produce release-notes text in the final message so the user can paste it straight into the GitHub release for the tag (title + body). Build it from the real history — `git log <previous ivue@ tag>..<bump commit> --oneline` — never from memory alone. - **Title**: `ivue@X.Y.Z — <the one-line story of the release>`. - **Body shape**: a short lead paragraph saying what the release IS; then `### Breaking` (omit when none) with each break stating the old behavior, the new behavior, and the migration; then `### Changed` / `### Fixed` bullets in plain sentences (no bare commit hashes); close with the measured numbers when the engine changed — gzipped size and coverage, stated as measurements. - Write for a reader who was not in the sessions: no internal codenames, no draft history — the same timeless-present discipline as the docs. ## Order of operations (summary) 1. Gates green → 2. bump `package.json` → 3. `chore(release): X.Y.Z` commit → 4. `git tag -a ivue@X.Y.Z -m "..." <bump-commit>` → 5. hand off: user pushes with `--follow-tags`, user runs `npm run release`.