[omarchybot]

Cutting a release meant committing a new version string to src/main.cpp first, so every release needed a code change and a pull request before it could be tagged. The version belongs to the release, not the code.

CMake now works it out at configure time and hands it to main.cpp as HYPE_VERSION, the only place it is used (hype --version). A release is built from the tag's tarball, which unpacks as hype-<version> — omarchy-pkgs' PKGBUILD already cds into exactly that — so the package reports the tag's version with no change there. A checkout reports git describe, such as 0.6.0-33-g4fc2621, and a source tree that is neither says dev. A new CLI test checks --version prints a version.

Releasing is now tagging vX.Y.Z and bumping pkgver in omarchy-pkgs. This replaces #55, which bumped the hardcoded string to 0.7.0.

🤖 Generated by Opus 5.5 in Claude Code.

[greptile-apps]

Confidence Score: 4/5

[Low impact] The change only affects the version Hype reports.

The PR appears safe to merge, with a non-blocking gap in the version test.

Findings

1.  Wrong versions pass the test ▶

Summary

Moves the application version from a hardcoded string to CMake's configure step.

• Hype reports the version of its release or checkout.

_{Reviews (1) · Last reviewed commit: "Take the version from the release, not t..." · Reviewed by Greptile}

[greptile-apps]

Wrong versions pass the test

test_version_comes_from_the_build also passes with the old hardcoded version or with dev on a release build. It cannot catch a failure in the version selection this PR adds. Add focused checks that configure a hype-1.2.3 source tree, a Git checkout, and a Git-free source tree, then assert their expected versions.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!