There is a particularly insidious class of bug that only reveals itself in multi-ecosystem software projects: version drift. Your package.json says 0.4.2, your build.zig.zon says 0.4.3, your Homebrew formula says 0.4.1, and your install script says development. No single file is technically wrong — but collectively, the system is in an inconsistent state that produces impossible-to-debug behavior. Users report bugs against version numbers that do not match the code they are actually running. Release automation silently publishes packages with mismatched metadata. And nobody notices until a production incident forces a forensic audit of the build artifacts.
The Synchronization Discipline
OMNI v0.4.3 is an intentionally small release with a singular, obsessive focus: achieving absolute version synchronization across every versioned file in the project. Nine files. Nine locations. One version string. No exceptions.
The synchronized targets span every layer of the project architecture: package.json and package-lock.json for the Node.js ecosystem, core/build.zig.zon for the Zig build system, src/index.ts and src/index.js for the TypeScript and JavaScript entry points, scripts/omni-deploy-edge.sh for the deployment pipeline, docs/index.html for the public-facing documentation, and omni.rb for the Homebrew formula. Every single one now reflects the exact same version string, verified by our CI pipeline on every commit.
Why a Whole Release?
You might reasonably ask: why dedicate an entire version number to what is essentially a metadata update? The answer is accountability. By tagging this synchronization as a distinct release, we create a permanent, auditable marker in our version history that says: “from this point forward, version consistency is a guaranteed property of the project.” Any future drift will be immediately detectable as a regression against this baseline.
The Hidden Cost of Drift
Version drift is not just a cosmetic problem. When a user reports that omni distill is producing incorrect output on version 0.4.2, and our debugging confirms the bug exists in 0.4.2 but was fixed in 0.4.3 — but the user’s Homebrew formula was accidentally still pointing to the 0.4.2 binary despite claiming to be 0.4.3 — we have wasted hours of engineering time on a phantom bug that was already resolved. Multiply this by every support interaction, every CI false alarm, every confused contributor, and version drift becomes one of the most expensive bugs a project can carry.
An Infrastructure Investment
This release is small on the surface but significant in what it prevents. By synchronizing all nine version locations and integrating version consistency checks into our release automation, we have eliminated an entire category of future bugs. Every release from this point forward will include automated verification that all version strings match before a single package is published. The investment is measured in minutes. The savings are measured in engineering weeks.