chore: re-version to v0.42.51.0 (natural next-off-master)

Maintainer override of the queue allocator's leap to 0.44.1.0 (it jumped past
in-flight sibling PR claims at 0.42.50/0.43.0/0.44.0). Take the natural next
slot in the 0.42.x line above the immediate sibling claim (0.42.50.0); a
merge re-bump resolves any collision if a cathedral PR lands first.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Garry Tan
2026-06-17 08:34:34 -07:00
co-authored by Claude Opus 4.8
parent b9275cddaf
commit 33700c8358
3 changed files with 4 additions and 4 deletions
+2 -2
View File
@@ -2,7 +2,7 @@
All notable changes to GBrain will be documented in this file.
## [0.44.1.0] - 2026-06-17
## [0.42.51.0] - 2026-06-17
**`gbrain sync` stops bottlenecking all its workers on a single database row, a malformed checkpoint can no longer wedge a source, and `gbrain doctor` tells an actively-running sync apart from a stuck one.** A slow source that fell behind HEAD could read as permanently stale even while it imported every cycle: sync was single-core-bound at the database layer, so handing it more workers didn't help, and the freshness check couldn't see that a sync was in fact running.
@@ -16,7 +16,7 @@ The root cause was the page-generation clock that backs the search cache. Every
- **A malformed checkpoint record can no longer wedge a source.** Checkpoint state is structurally constrained, repaired automatically on upgrade, and the loader survives a bad record instead of discarding all banked progress for that source.
- **`gbrain sync --force-break-lock` is honest when there is no lock.** It now says plainly that nothing was held and points at how to inspect a genuinely wedged sync, instead of a terse no-op that read like a successful unwedge.
### To take advantage of v0.44.1.0
### To take advantage of v0.42.51.0
`gbrain upgrade`, then `gbrain doctor`. Existing brains pick up the contention-free clock and the checkpoint integrity constraint automatically on the next migration; the search cache rebuilds itself on first query. Nothing to configure.
## [0.42.49.0] - 2026-06-16
+1 -1
View File
@@ -1 +1 @@
0.44.1.0
0.42.51.0
+1 -1
View File
@@ -143,5 +143,5 @@
"bun": ">=1.3.10"
},
"license": "MIT",
"version": "0.44.1.0"
"version": "0.42.51.0"
}