Skip to content

Latest commit

 

History

History
57 lines (38 loc) · 1.77 KB

File metadata and controls

57 lines (38 loc) · 1.77 KB

Release Runbook

Zaileys ships releases as GitHub Releases only. Publishing to npm is a deliberate manual step performed by the maintainer — it is intentionally not automated.

1. Cut a release

# 1. Record the change set (choose bump: patch / minor / major)
pnpm changeset

# 2. Apply version bumps + update CHANGELOG
pnpm changeset version
pnpm install

# 3. Commit the version bump
git add -A
git commit -m "chore(release): version packages"

# 4. Tag the release (must match the new package.json version)
git tag vX.Y.Z

# 5. Push the tag — this triggers .github/workflows/release.yml
git push --tags

Pushing a v* tag runs the Release workflow, which:

  • builds the package (pnpm build),
  • packs the tarball (pnpm pack -> zaileys-X.Y.Z.tgz),
  • creates a GitHub Release with autogenerated release notes and the tarball attached.

2. Publish to npm (MANUAL — maintainer only)

After the GitHub Release is created, publish to npm locally:

pnpm build
npm publish
# or: pnpm publish

This step is intentionally not in CI. No NPM_TOKEN lives in the CI pipeline; the npm release is a deliberate, user-attributed action (project policy / threat model T-08-05).

3. Changeset base branch

During the v4 cycle, .changeset/config.json uses "baseBranch": "v4". Once v4 merges to main, retarget it:

pnpm pkg --help >/dev/null  # (config edit is manual)
# set .changeset/config.json "baseBranch" -> "main"

The v4 -> main merge timing is maintainer-controlled.

4. Pull request changesets

Every PR that changes published behavior must include a changeset (enforced by .github/workflows/changeset-check.yml). Docs-only or chore PRs may add the no-changeset label to skip the check, or run pnpm changeset --empty.