chore: set up release-please, bump Node to >=21, disable darwin-x64 npm builds

.github/workflows/release-please.yml

@@ -0,0 +1,37 @@
+name: release-please
+
+# Maintains a single open "release PR" on main that bumps all workspace
+# versions, updates per-crate CHANGELOG.md files, and updates the
+# .release-please-manifest.json based on Conventional Commits since the
+# last release. Merging that PR creates a GitHub Release and a v{X.Y.Z}
+# tag.
+#
+# The downstream workflows trigger off the GitHub Release publish event
+# (release.yml → crates.io, npm-build-publish.yml → npm) rather than the
+# tag push. This avoids the GitHub Actions limitation where tags pushed
+# by GITHUB_TOKEN don't fire `on: push: tags:` workflows — which would
+# otherwise require a custom PAT.
+#
+# Maintainers don't run anything by hand:
+#   1. Land conventional-commit PRs into main.
+#   2. Merge the release-please PR when ready to ship.
+#
+# See docs/GITHUB_OPERATIONS.md → "Cutting a release" for details.
+
+on:
+  push:
+    branches: [main]
+  workflow_dispatch: {}
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  release-please:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: googleapis/release-please-action@v4
+        with:
+          config-file: release-please-config.json
+          manifest-file: .release-please-manifest.json

.github/workflows/release.yml

@@ -1,8 +1,16 @@
 name: release
 
-# Tag-triggered publish to crates.io. Stable tags (v0.1.0) mark the
-# GitHub release as latest; pre-release tags (v0.1.0-rc.1) mark it as
-# prerelease so it doesn't show as "Latest release" on the repo home.
+# Publish to crates.io.
+#
+# Triggered by:
+#   - a GitHub Release published event (release-please drives this on
+#     merge of the release PR), or
+#   - a direct `git push origin v0.X.Y` tag push (emergency releases),
+#   - or a manual workflow_dispatch with an explicit existing tag.
+#
+# Stable tags (v0.1.0) mark the GitHub release as latest; pre-release
+# tags (v0.1.0-rc.1) mark it as prerelease so it doesn't show as
+# "Latest release" on the repo home.
 #
 # Publishing is destructive — version numbers on crates.io are
 # permanent. This workflow re-runs the full test matrix before
@@ -11,6 +19,12 @@ name: release
 # consistent for downstream crates.
 
 on:
+  # release-please drives most releases by merging the release PR and
+  # publishing a GitHub Release; that fires the `release: published`
+  # event below. Direct `git push origin v0.X.Y` tag pushes also work
+  # (e.g. for emergency releases that bypass release-please).
+  release:
+    types: [published]
   push:
     tags:
       - "v*.*.*-rc.*"
@@ -37,7 +51,7 @@ jobs:
     steps:
       - uses: actions/checkout@v6
         with:
-          ref: ${{ github.event.inputs.tag || github.ref }}
+          ref: ${{ github.event.inputs.tag || github.event.release.tag_name || github.ref }}
 
       - name: Install system libraries
         run: sudo apt-get update -q && sudo apt-get install -y libfontconfig1-dev mold protobuf-compiler
@@ -80,7 +94,7 @@ jobs:
     steps:
       - uses: actions/checkout@v6
         with:
-          ref: ${{ github.event.inputs.tag || github.ref }}
+          ref: ${{ github.event.inputs.tag || github.event.release.tag_name || github.ref }}
 
       - name: Install system libraries
         run: sudo apt-get update -q && sudo apt-get install -y libfontconfig1-dev mold protobuf-compiler
@@ -95,9 +109,10 @@ jobs:
         env:
           REF_NAME: ${{ github.ref_name }}
           INPUT_TAG: ${{ github.event.inputs.tag }}
+          RELEASE_TAG: ${{ github.event.release.tag_name }}
         run: |
           set -euo pipefail
-          TAG="${INPUT_TAG:-$REF_NAME}"
+          TAG="${INPUT_TAG:-${RELEASE_TAG:-$REF_NAME}}"
           # Defense in depth: tags coming from workflow_dispatch are
           # user-supplied. Enforce a strict `vX.Y.Z` / `vX.Y.Z-rc.N`
           # shape before letting the name flow into cargo/git commands.

.release-please-manifest.json

@@ -0,0 +1,17 @@
+{
+  "hyperdb-api-core": "0.1.1",
+  "hyperdb-api": "0.1.1",
+  "hyperdb-api-salesforce": "0.1.1",
+  "hyperdb-mcp": "0.1.1",
+  "hyperdb-bootstrap": "0.1.1",
+  "sea-query-hyperdb": "0.1.1",
+  "hyperdb-api-node": "0.1.1",
+  "hyperdb-mcp/npm/darwin-arm64": "0.1.1",
+  "hyperdb-mcp/npm/linux-x64-gnu": "0.1.1",
+  "hyperdb-mcp/npm/win32-x64-msvc": "0.1.1",
+  "hyperdb-api-node/npm/darwin-arm64": "0.1.1",
+  "hyperdb-api-node/npm/linux-arm64-gnu": "0.1.1",
+  "hyperdb-api-node/npm/linux-x64-gnu": "0.1.1",
+  "hyperdb-api-node/npm/linux-x64-musl": "0.1.1",
+  "hyperdb-api-node/npm/win32-x64-msvc": "0.1.1"
+}

CONTRIBUTING.md

@@ -53,23 +53,23 @@ When a lint genuinely cannot be satisfied for a given site, suppress it with `#[
 
 # Contribution Checklist
 
-- [x] Clean, simple, well styled code — conforms to [docs/RUST_GUIDELINES.md](docs/RUST_GUIDELINES.md)
-- [x] Commits should be atomic and messages must be descriptive. Related issues should be mentioned by Issue number.
-- [x] Comments
+- [ ] Clean, simple, well styled code — conforms to [docs/RUST_GUIDELINES.md](docs/RUST_GUIDELINES.md)
+- [ ] Commits should be atomic and messages must be descriptive. Related issues should be mentioned by Issue number.
+- [ ] Comments
   - Module-level & function-level comments.
   - Comments on complex blocks of code or algorithms (include references to sources).
-- [x] Tests
+- [ ] Tests
   - The test suite, if provided, must be complete and pass
   - Increase code coverage, not versa.
   - See `hyperdb-api/tests/` for integration test patterns and `hyperdb-api/tests/common/mod.rs` for shared test helpers. Borrow inspiration from existing tests.
-- [x] Dependencies
+- [ ] Dependencies
   - Minimize number of dependencies.
   - Prefer MIT, Apache-2.0, BSD-3-Clause, ISC, and MPL-2.0 licenses (consistent with this project's dual MIT/Apache-2.0 license). Enforced by `cargo deny check`; see [deny.toml](deny.toml).
-- [x] Documentation
+- [ ] Documentation
   - Public API items have `///` doc comments with examples
   - README.md and DEVELOPMENT.md updated if behavior changes
   - New features include an example in `hyperdb-api/examples/` when applicable
-- [x] Reviews
+- [ ] Reviews
   - Changes must be approved via peer code review
 
 # Signed Commits
@@ -85,6 +85,11 @@ git config --global commit.gpgsign true
 git config --global tag.gpgsign true
 ```
 
+> If you have **multiple GitHub accounts** (e.g. work + personal) on the same
+> machine, swap `--global` for `--local` and run the commands from inside
+> this repo's checkout. That keeps the signing key + email scoped to this
+> clone instead of overriding your global identity for every other repo.
+
 If the key is not already registered on your GitHub account, add it under **Settings → SSH and GPG keys → New SSH key** with **Key type: Signing Key**. If it's already there as an Authentication Key, you don't need to add it again — GitHub verifies SSH signatures against every key on your account regardless of the type label. Trying to add the same key twice will fail with "Key is already in use"; that's fine.
 
 Verify with `git commit --allow-empty -m "test" && git log --show-signature -1` — you should see `Good "git" signature for <your email>`. After pushing, the commit shows a green **Verified** badge on GitHub.
@@ -165,45 +170,42 @@ chore: update arrow dependency to 56
 
 # Release Process
 
-> **Current state:** changelogs and version bumps are maintained **manually**
-> today. A [`release-please-config.json`](release-please-config.json) is checked
-> in for the future, but no GitHub Actions workflow currently invokes Release
-> Please — the maintainer-facing recipe in
-> [`docs/GITHUB_OPERATIONS.md`](docs/GITHUB_OPERATIONS.md) is authoritative.
-> When/if Release Please is wired up, this section will be revised.
-
-## Authoring changes (every contributor)
+This repo uses [release-please](https://github.com/googleapis/release-please)
+to fully automate version bumps, changelog generation, tagging, and the
+crates.io / npm publish dance.
 
-When a PR adds, changes, or removes any public API surface in a publishable
-crate (see the [Published Crates](#published-crates) table below), append a
-bullet to the `## [Unreleased]` section of that crate's `CHANGELOG.md` under
-the appropriate [Keep a Changelog](https://keepachangelog.com/) heading:
+## What contributors do
 
-- `### Added` — new public APIs, modules, tools, features.
-- `### Changed` — behavior changes that aren't breaking.
-- `### Deprecated` — APIs scheduled for removal.
-- `### Removed` — APIs removed in this release.
-- `### Fixed` — bug fixes that affect behavior.
-- `### Security` — security-relevant fixes.
+**Use [Conventional Commits](https://www.conventionalcommits.org/) for every
+PR title.** That's it. release-please reads the merged commits to figure out
+the next version and generate the changelog automatically. Commit-message
+prefixes drive the version bump per the table in
+[Commit Types and Version Impact](#commit-types-and-version-impact) above.
 
-Internal refactors that do not change the public API surface do not require a
-changelog entry. The `## [Unreleased]` section is promoted to a dated
-`## [X.Y.Z] - YYYY-MM-DD` section by the maintainer at release time.
+Contributors do **not** edit `CHANGELOG.md` files by hand and do **not** bump
+versions in `Cargo.toml` / `package.json` manually. Both are regenerated by
+release-please on every push to `main`.
 
-## Cutting a release (maintainer)
+## What maintainers do
 
-The end-to-end recipe lives in [`docs/GITHUB_OPERATIONS.md`](docs/GITHUB_OPERATIONS.md).
+The end-to-end flow lives in
+[`docs/GITHUB_OPERATIONS.md` → Cutting a release](docs/GITHUB_OPERATIONS.md#cutting-a-release).
 Summary:
 
-1. Bump every publishable crate's `Cargo.toml` `version` (and `package.json`
-   for `hyperdb-api-node`) to the new tag in lockstep.
-2. In each crate's `CHANGELOG.md`, keep an empty `## [Unreleased]` heading
-   at the top, then add `## [X.Y.Z] - YYYY-MM-DD` below it with all bullets
-   that accumulated under `[Unreleased]` since the last release.
-3. Open a release PR, merge to `main`, then tag the merge commit
-   (e.g. `v0.2.0`).
-4. CI publishes Rust crates to crates.io and `hyperdb-api-node` to npm via the
-   tag-triggered workflows.
+1. Land conventional-commit PRs into `main`.
+2. release-please opens (or updates) a single PR titled
+   `chore(main): release X.Y.Z` containing the version bumps and CHANGELOG
+   updates.
+3. Review and **merge** that PR when ready to ship. release-please tags the
+   merge commit and creates the GitHub Release.
+4. The tag triggers [`release.yml`](.github/workflows/release.yml)
+   (crates.io publish) and the GitHub Release triggers
+   [`npm-build-publish.yml`](.github/workflows/npm-build-publish.yml) (npm publish).
+   No further maintainer action is required.
+
+For pre-releases (`-rc.N`, `-alpha.N`, `-beta.N`), include a `Release-As:`
+footer in a commit on `main` — see
+[`docs/GITHUB_OPERATIONS.md`](docs/GITHUB_OPERATIONS.md#pre-releases).
 
 ## Published Crates
 

DEVELOPMENT.md

@@ -91,7 +91,7 @@ graph LR
 
 The `hyperdb-api` crate has **zero feature flags** — all capabilities (TLS, pooling, geography,
 transactions, chrono) are always enabled. This simplifies dependency management and matches
-the C++/Python/Java APIs. Domain-specific functionality lives in companion crates instead.
+the C++/Python/Java APIs. Domain-specific functionality lives in companion crates instead. This may change before 1.0.0 if it's found that certain feature flags can greatly reduce the number of dependencies for users who don't need them, reduce the overall binary size and build time.
 
 ---
 

README.md

@@ -89,38 +89,32 @@ Add to your `Cargo.toml`:
 hyperdb-api = { path = "hyperdb-api" }
 ```
 
-#### Pre-built binaries
+#### Installing the CLIs
 
-Release archives for the `hyperdb-mcp` and `hyperdb-bootstrap` CLIs are
-attached to every tagged release on the
-[Releases page](https://github.com/tableau/hyper-api-rust/releases).
-Supported targets: `x86_64-unknown-linux-gnu`, `aarch64-apple-darwin`,
-`x86_64-apple-darwin`, `x86_64-pc-windows-msvc`.
+`hyperdb-mcp` and `hyperdb-bootstrap` ship two ways:
 
-Linux / macOS:
+**Via npm** (recommended for `hyperdb-mcp`; bundles a matching `hyperd`):
 
 ```bash
-TAG=v0.1.0
-TARGET=x86_64-unknown-linux-gnu   # or aarch64-apple-darwin, x86_64-apple-darwin
-BIN=hyperdb-mcp                   # or hyperdb-bootstrap
-curl -fsSL "https://github.com/tableau/hyper-api-rust/releases/download/${TAG}/${BIN}-${TAG}-${TARGET}.tar.gz" \
-  | tar -xz -C /tmp
-sudo install "/tmp/${BIN}-${TAG}-${TARGET}/${BIN}" /usr/local/bin/
+npm install -g hyperdb-mcp
 ```
 
-Windows: download the `.zip` from the Releases page and extract the
-`.exe` to somewhere on `%PATH%`.
+Supported platforms: macOS ARM64 (Apple Silicon), Linux x64 (glibc),
+Windows x64. Intel macOS is built-from-source only at the moment — see
+the platform table in [`hyperdb-mcp/README.md`](hyperdb-mcp/README.md#installation).
 
-Verify downloads against the `SHA256SUMS.txt` attached to the release:
+**Via crates.io** (compiles from source; no bundled `hyperd`):
 
 ```bash
-sha256sum -c SHA256SUMS.txt
+cargo install hyperdb-mcp
+cargo install hyperdb-bootstrap
 ```
 
-**macOS Gatekeeper:** these binaries are unsigned. `curl | tar` extraction
-does not set the quarantine xattr, so the one-liner above works cleanly.
-If a `.tar.gz` downloaded via browser gets quarantined, clear it once with
-`xattr -d com.apple.quarantine <binary>`.
+`hyperdb-bootstrap` will then download a compatible `hyperd` for you:
+
+```bash
+hyperdb-bootstrap download
+```
 
 ### Environment Setup