Repository navigation
FastDB 0.2.0
FastDB 0.2.0 provides portable record and object-graph payloads through one C++ Core, a stable C ABI, Rust, Python, and TypeScript/WebAssembly. Compilation, canonical identity, binary layout, checked lifetime and four-language code generation share the same Core implementation.
Breaking changes remove the superseded portable APIs and rename the standalone AoS engine to RecordEngine. Legacy standalone object storage and serialization retain their documented roles. Native builders now release their owned layers; TypeScript layer handles are borrowed from the parent.
Source: ceebed2edbef580ba0a42dcd28dadf9628894523 (PR #35). Payload ABI remains version 1 with exactly 117 exports.
Assets include Linux x86-64 and macOS arm64 Core bundles, both Rust crate archives, Python 3.10–3.14 and 3.14t wheels for manylinux_2_28 x86-64/macOS arm64, a Python sdist, and the TypeScript/WASM package. The Core bundle manifest records its build platform and runtime requirements. Windows native support and additional platform guarantees remain separately tracked.
Rust registry consumers install the matching Core bundle and set FASTDB_PAYLOAD_LINK_MODE=system and FASTDB_PAYLOAD_SYSTEM_LIB_DIR to its absolute lib directory. See the crate READMEs for runtime loader configuration.
Every asset is tied to the source commit and SHA-256 in release-manifest.json. Original third-party license notices are included in the distributed packages.
Verification: main tests and main artifact build.
Published packages:
- fastdb4py 0.2.0 on PyPI
- fastdb4ts 0.2.0 on npm
- fastdb 0.2.0 and fastdb-sys 0.2.0 on crates.io
All registry file hashes match the release manifest. Fresh public-registry installs passed 344 Python tests and Rust/Node compile, build, open, checked-view invalidation and detached-materialization checks. Linux ASan/LeakSanitizer/UBSan passed all 44 native tests, and both fuzz targets completed 1000 runs.
See publication-receipt.json for exact CI run IDs and verification results. The npm registry's initial processing delay was resolved by a verification-only retry; the already matching tarball was not uploaded again.