Friction limits adoption. Every manual step in an upgrade process is a chance for the user to say “not today” — and “not today” has a way of becoming “not ever.” We have seen it happen with brilliant tools that died not because they lacked value, but because their users quietly fell three versions behind and never caught up. OMNI v0.4.0 is our declaration of war against upgrade friction, delivering an intelligent update framework that meets developers exactly where they are.
Smart Update Detection
The new omni update command does not just check for new versions — it understands how you installed OMNI and provides contextually appropriate upgrade instructions. If you installed via Homebrew, it tells you to run brew upgrade omni. If you used our curl installer, it provides the exact download URL for the latest binary. If you built from source, it points you to the release tag. This intelligence is not hardcoded — the engine inspects the installation indicators at runtime and dynamically determines the correct upgrade path.
Behind the scenes, the update checker queries the GitHub Releases API, caches the result locally to avoid redundant network requests, and presents the information in a clean, scannable terminal format. The check is lightweight, non-blocking, and respects offline environments by gracefully degrading to cached data when no network is available.
A New Front Door
Alongside the CLI improvements, we introduced a completely redesigned OMNI landing page. The new design communicates OMNI’s value proposition in under five seconds — a bold visual statement backed by concrete performance metrics and a one-line installation command. This is not vanity work. Your landing page is often the first and only chance to convert a curious developer into an active user, and we invested significant design effort into making that conversion as frictionless as possible.
The Homebrew Path Problem
One of the most frustrating bugs we fixed in this release had been silently breaking installations for Homebrew users for weeks. The omni setup command was constructing paths using the versioned Homebrew Cellar directory — something like /opt/homebrew/Cellar/omni/0.3.9/bin/omni — which meant that every brew upgrade would break all existing symlinks and hook references. The fix is elegant: we now use the stable /opt/omni prefix path, which Homebrew maintains as a persistent symlink to the current version. Upgrades are now truly seamless — no broken references, no manual re-linking, no post-upgrade omni init required.
Eliminating Self-Referencing Symlinks
A related edge case was also resolved. Under certain installation sequences, omni setup would attempt to create a symlink where the source and destination were the same file — producing a self-referencing symlink that caused infinite loops when the shell tried to resolve the binary path. We added a simple but critical guard: if the source and destination paths resolve to the same inode, the setup command skips the symlink creation entirely and reports success. This defensive check prevents an entire category of installation-time crashes.
Dynamic Build Versioning
The Zig build system (build.zig) was updated to automatically embed the current release version into the compiled binary, even when the -Dversion flag is not explicitly specified. Previously, omitting this flag would produce a binary that identified itself as “development” — confusing for anyone running a release build. The default now falls through to the version string defined in the build manifest, ensuring that every compiled artifact carries accurate version metadata.
The Release Machinery
Under the hood, the release script (omni-release.sh) was expanded to synchronize version strings across nine locations — up from eight — adding core/build.zig to the list of automatically bumped files. The pull request template was also simplified to a checklist-only format, reducing the ceremony around contributions and focusing reviewer attention on the code rather than elaborate PR descriptions.
Removing Barriers
The common thread through every change in v0.4.0 is the removal of barriers. Barriers to upgrading, barriers to discovering, barriers to trusting that the version you are running is the version you think you are running. When these barriers are gone, adoption becomes natural because the tool simply works — silently, correctly, and without demanding your attention.