Releasing

Where things stand

0.1.0-alpha.1 was published on 2026-09-10 with a one-shot token; the source tree is at 0.1.0-alpha.1. That first publish attached no provenance, because npm only attests a public repository, and trusted publishing over OIDC has not yet succeeded. The checklist below covers what is left before the next release.

GitHub is boussadjra/queryweave. npm is the queryweave org, which owns the @queryweave/* scope. Those are independent names: do not move the git repository to queryweave/queryweave.

The Release workflow only runs when github.repository is boussadjra/queryweave.

Every public package shares one version. pnpm publish:packages publishes in dependency order, skips versions already on the registry, and chooses the dist-tag from the policy below. Do not use changeset publish; the lockstep publisher is the source of truth.

Dist-tags

npm gave the first version ever published the latest tag, whatever its prerelease id. The policy follows that fact rather than fighting it:

• Until a stable version exists, every publish goes to latest, so pnpm add @queryweave/core resolves the newest prerelease. There are no channel tags to remember, and the docs use bare package names. The alpha tag that the first publish created stays behind at 0.1.0-alpha.1 and is not maintained.
• Once 0.1.0 is on the registry, latest holds the stable line and a prerelease is published under its own id: 0.2.0-beta.0 under beta, 0.2.0-rc.0 under rc.

pnpm publish:packages --tag <tag> overrides the policy for one run.

Cutting a new prerelease line

Changesets is in pre mode, which decides the prerelease id of every automated version bump. Moving from alpha to beta needs both the pre-mode tag and the version to change, in this order:

pnpm changeset pre exit
pnpm changeset pre enter beta
pnpm version:set -- 0.1.0-beta.0

Commit the three results together. Later changesets then produce 0.1.0-beta.1, 0.1.0-beta.2, and so on through the Version PR.

Do not run version:set alone

pnpm version:set -- 0.1.0-beta.0 on its own leaves pre mode at alpha. The next changeset version then computes 0.1.0-alpha.2 from the recorded alpha baseline and writes that back over the beta version. Exit and re-enter pre mode first.

Do not run pnpm version:set and changeset version for the same release. Leaving pre mode for the first stable release is pnpm changeset pre exit followed by a normal Version PR.

Before the next release

1. Make the GitHub repository public. Provenance attestations, the repository links in every package manifest, the ADR links in this site, and private vulnerability reporting all depend on it.

2. On each package page (npmjs.com/package/@queryweave/core/access, and the same for testing, browser, server, node, standard-schema, vue, vue-router, nuxt), confirm a GitHub Actions trusted publisher is attached:

   • Organization or user: boussadjra
   • Repository: queryweave
   • Workflow filename: release.yml
   • Environment name: release

   The first-publish runs logged Skipped OIDC because the packages did not exist yet; a publish that still logs it means this step is incomplete.

3. Require 2FA and disallow tokens on those packages. Confirm no NPM_TOKEN secret remains on the repository; the repository variable NPM_TRUSTED_PUBLISHING is already true.

4. Add a changeset for the release, merge, then merge the Version PR. Confirm the tag afterwards:

   npm view @queryweave/core version
   npm dist-tag ls @queryweave/core

Later releases

A user-visible change needs a changeset in the pull request. Merging to main opens a Version PR that bumps the lockstep version and writes CHANGELOG.md. Merging that PR publishes with pnpm publish:packages when NPM_TRUSTED_PUBLISHING is true.

The Release workflow never runs from a fork or a pull request. The publish jobs request id-token: write only for themselves.

What is still deferred

Throttling, coalescing, and cancellation of transitions; date, JSON, object, and tuple codecs; per-parameter omission policy; and server response contribution are on the roadmap. Transitions are already serialized per runtime, so debouncing at the call site is about history entries, not correctness.