v0.7.0 — release ceremony: bump from v0.6.0 → v0.7.0 with smooth user-schema upgrade verified

Why v0.7.0 (not v0.7.0)

Per Human directive on !199 (merged) (2026-05-18): "This is a huge project. After this done, we need to bump the version to v0.7.0, and make sure plugin upgrade can smoothly upgrade and migrate users' local schema."

The work shipped to dev since v0.6.0 is substantial enough that v0.7.0 would understate the changeset. Bumping straight to v0.7.0.

What's merged on dev since v0.6.0

Plugin-shape changes (visible to users)

  • #2904 (closed) / !198 (merged) — slim-skills (Phase A + B): tmb_planning 292→189 LOC, tmb_review 274→195 LOC; 6 new mechanisms (4 composites + 2 hooks); boundary-audit + research docs lifted into DETERMINISM.md
  • #2922 (closed) / !194 (merged)_spawnFn mock overrides TMB_DISABLE_REMOTE_SYNC env in sync backend
  • #2923 (closed) / !196 (merged) — L6 step-10 prompt rewrite (drop explicit consultant naming)
  • #2924 (closed) / !195 (merged) — L6 step-02 rename + provider-agnostic prompt
  • #2925 (closed) / !197 (merged) — P1 prefix-mismatch fix: 5 hooks + helper + lint (4 safety gates were silently disabled by tmb: prefix)
  • #2905 (closed) Phase 1 / !199 (merged) — FTS5 search infrastructure + 3 new MCP search tools (discussion_search, audit_search, file_registry_search); cursor pagination on 6 existing list tools; schema v3
  • #2905 (closed) Phase 2 / !200 (merged) — ONNX embedding pipeline (bge-small-en-v1.5) + hybrid RRF ranking + skill updates; schema v4

Schema migrations users will hit

  • v2 → v3: FTS5 virtual tables + sync triggers + backfill of existing rows
  • v3 → v4: 3 embedding tables; background backfill on server startup (lazy model load + fire-and-forget on first server boot)
  • Both migrations are defensive: tableExists() guards mean partial-DB upgrade paths (L0 install-smoke verified) work cleanly
  • Pre-migration .bak files written per leg (pre-v3.*.bak, pre-v4.*.bak)

New install-weight cost (worth surfacing in release notes)

  • @huggingface/transformers + onnxruntime-node native binary (~50MB, prebuilt for darwin x64/arm64, linux x64/arm64, win x64)
  • Lazy-downloaded model bge-small-en-v1.5 (~33MB, downloaded to ~/.cache/huggingface/hub/ on first embedding call)
  • Total first-run download: ~83MB; subsequent runs use cache
  • Users on unsupported platforms (linux-armv7, FreeBSD, etc.) gracefully degrade to FTS5-only search with warning: 'semantic_unavailable' — never hard-fail

Plan

Step 1 — bump-version

Run scripts/maintenance/bump-version.sh 0.8.0 (the v0.6.0 release pattern). Confirms:

  • plugin.json version
  • bun.lock version
  • gemini-extension.json version (or annotate placeholder status)
  • CHANGELOG.md new section

Step 2 — author CHANGELOG entry

Cover all 7 MRs above. Frame for end-users:

  • New: hybrid keyword + semantic search (*_search MCP tools) — replaces dumping rows; ~80% token reduction on read-heavy turns when bro queries the DB
  • New: schema v4 migration with auto-backfill of FTS5 + embeddings on first server boot post-upgrade
  • Improved: 4 silently-disabled safety-gate hooks (pr-reviewer-no-worktree, require-task-spec, require-feature-branch-active, pr-reviewer-spawn-prompt-shape) now fire correctly under all CC role-naming contexts
  • Improved: tmb_planning and tmb_review skills slimmed by ~30%; bro's context budget drops accordingly
  • Install: +50MB native binary, +33MB lazy model download (first embedding call); semantic search gracefully degrades to FTS5-only on unsupported platforms

Step 3 — verify smooth upgrade path

The v0.6.0 → v0.7.0 user-machine upgrade story tested via:

  • L0 install-smoke: legacy-v1 synthetic DB → migrates to v4, schema_version + onboarded marker preserved, .bak files written per leg
  • L2 schema-upgrade tests: v2→v3→v4 path with real-data fixtures verifies FTS5 backfill, embedding table creation, FK CASCADE behavior
  • Manual check on this dev machine: run bun run build + restart MCP, observe migration banner + embedding backfill log lines, verify pre-existing audit rows queryable via new audit_search

Step 4 — RC or direct stable

Open question for Human: per the v0.6.0 pattern, the release went through 8 RCs before stable. v0.7.0's scope is comparable. Options:

  • A — direct stable: tag v0.7.0 immediately; rely on the L0-L4 + manual upgrade verification we already have
  • B — RC chain: tag v0.7.0-rc.1, soak in marketplace-rc for ~1 week, iterate on real-user upgrade reports, then stable
  • C — single RC: tag v0.7.0-rc.1, run L6 chain end-to-end once, if green tag stable within 24h

Recommendation: C (single RC). The schema migration + native binary are the riskiest pieces; one RC cycle catches platform-specific install failures without months of soak.

Step 5 — tag + release

Run scripts/release.sh (or follow the v0.6.0 manual pattern given the GH-suspended state). Push tag to GitLab; publish release notes.

Step 6 — marketplace channel sync

Update marketplace-rc ref to the new tag (if RC chain); update marketplace ref to stable on final.

Acceptance criteria

  • All 4 version-sync points updated to v0.7.0 (plugin.json, bun.lock, gemini-extension.json, CHANGELOG.md top section)
  • CHANGELOG.md v0.7.0 section covers all 7 merged MRs in user-facing language
  • Tag created on GitLab; release published; release notes link to CHANGELOG entry
  • marketplace-rc / marketplace ref updated per chosen path (A/B/C)
  • Smooth-upgrade verified end-to-end (L0 install-smoke + L2 schema-upgrade green + manual local upgrade observed)

Out of scope

  • Bumping the model (defer to a follow-up if bge-small-en-v1.5 proves insufficient)
  • Adding sqlite-vec (defer per !2905 plan)
  • Migrating remaining v0.7.0 backlog issues into v0.7.0 scope (open question — see Coordination)

Coordination

  • ~19 open v0.7.0 issues remain (cap-field-sizes, /scan-debounce, cache-friendly-hooks, pr-reviewer-base-branch, roundtable-cost, SWE-worktree-overreads, inline-design-docs, mcp_safe-wrapper, shrink-MCP-surface, subagent-fanout-cap, compact-responses, impersonation-guard-cost, prompt-cache-discipline, P1-hallucination, per-spawn-hook-chain, measurement-harness, !2927, !2928, !2903 B1 schema-provenance)
  • Open question: relabel them v0.7.x patch / v0.9 minor? Or ship v0.7.0 with what's merged and triage the backlog post-release?

Note on source

Filed after !200 (merged) merge per Human directive on !199 (merged). The v0.6.0 → v0.7.0 jump (skipping v0.7.x) is intentional — the merged work changes the architecture enough that a minor-version bump understates the impact.

Edited by Zax Shen