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_planning292→189 LOC,tmb_review274→195 LOC; 6 new mechanisms (4 composites + 2 hooks); boundary-audit + research docs lifted intoDETERMINISM.md - #2922 (closed) / !194 (merged) —
_spawnFnmock overridesTMB_DISABLE_REMOTE_SYNCenv 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
.bakfiles written per leg (pre-v3.*.bak,pre-v4.*.bak)
New install-weight cost (worth surfacing in release notes)
@huggingface/transformers+onnxruntime-nodenative 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.jsonversionbun.lockversiongemini-extension.jsonversion (or annotate placeholder status)CHANGELOG.mdnew section
Step 2 — author CHANGELOG entry
Cover all 7 MRs above. Frame for end-users:
- New: hybrid keyword + semantic search (
*_searchMCP 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_planningandtmb_reviewskills 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,
.bakfiles 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-existingauditrows queryable via newaudit_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.0immediately; rely on the L0-L4 + manual upgrade verification we already have - B — RC chain: tag
v0.7.0-rc.1, soak inmarketplace-rcfor ~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.