| name | release |
| description | Cut or diagnose a BrowserMesh release - Release Please PR, protected tag, npm Trusted Publishing over OIDC, and MCP Registry publication. Use when preparing a release, reviewing a Release PR, investigating a failed publish, or asked why a version did not reach npm or the registry. |
Releasing BrowserMesh
TODO — release is currently blocked on a maintainer action
npm Trusted Publishing is not configured for the browsermesh package. This is not a code
problem and no change in this repository fixes it.
- 0.2.0 could not publish over OIDC and was pushed by hand.
publish.yml will fail the same way on the next version until a trusted publisher naming this
repository, publish.yml, and the npm environment is added on npmjs.com.- Because registry publication runs after
npm publish in the same job, it has not run either. The
MCP Registry's latest entry is still 0.1.5 pointing at the old multi-agent-browser-mcp
name.
Configuring the trusted publisher first lets the next release correct the registry on its own. Do
not work around this by publishing manually again without saying so — see
docs/IMPLEMENTATION_STATUS.md.
Also outstanding and maintainer-only: GitHub repository topics are unset.
The chain
Conventional Commit PR title
→ reviewed PR with green required checks
→ merge to master
→ release-please updates a Release PR
→ maintainer merges the Release PR
→ release-please creates the vX.Y.Z tag and GitHub Release
→ publish workflow verifies source and installed tarball
→ npm Trusted Publishing (OIDC)
→ MCP Registry publication (GitHub OIDC)
No ordinary push or feature PR publishes anything. Merging the Release PR is the only maintainer
gesture that starts a release.
What bumps a version
release-please-config.json uses release-type: node with bump-minor-pre-major and
bump-patch-for-minor-pre-major. Pre-1.0, feat and fix both produce a patch. chore, docs,
ci, test, build, and refactor produce no release — use them for tooling changes that should
not cut a version.
PR titles are validated against feat fix docs refactor perf test build ci chore revert, and the
subject must start lowercase.
Version consistency
Four places carry the version and must agree: package.json, both version fields in server.json,
and the generated src/infrastructure/generated/version.ts. Release Please updates all of them via
extra-files. npm run check:version fails on drift and runs as pretypecheck, so a stale
generated module turns typecheck red before anything is type-checked.
Installed-package verification additionally requires the MCP serverInfo.version handshake to
equal the installed manifest and the registry manifest.
Before proposing a release
npm run verify
npm run verify:package
verify:package respects BROWSERMESH_HEADLESS; CI runs it headed under Xvfb on Linux and
headless on Windows.
Verifying a published version
PACKAGE_VERSION="$(node -p "require('./package.json').version")"
npm view "browsermesh@$PACKAGE_VERSION" version dist-tags --json
curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.scrollDynasty/browsermesh"
npx -y "browsermesh@$PACKAGE_VERSION"
The last command stays running because it is an stdio server. Stop it by closing the client; that
is not a hang.
A failed publication
Never delete, move, or retag a release to hide a failure, and never npm unpublish. npm versions
are immutable.
- Fix the workflow or package problem through a normal PR.
- Let release-please prepare a new patch version.
- Merge the new Release PR and publish the new immutable version.
Requires explicit maintainer authorisation
Never perform these autonomously: the first npm bootstrap publication, merging a Release PR,
changing dist-tags, deprecating or unpublishing, rotating release credentials, or changing
protected-branch or environment policy.
Reference
docs/releasing.md for the full one-time GitHub and npm setup, including branch rulesets, the
RELEASE_PLEASE_TOKEN fine-grained PAT, CodeQL, and Dependabot.
