chore: wire release-please to bump CMake + version.hpp on every release#10
Merged
Conversation
release-please was installed in PR #9 but its `extra-files` arrays were empty — it only bumped .release-please-manifest.json on each release, leaving the actual source-of-truth version constants stale: framework/_meta/include/phyriad/version.hpp stuck at 1.0.0 CMakeLists.txt stuck at 1.0.0 + rc2 apps/ayama/CMakeLists.txt stuck at 0.1.0 GitHub Releases meanwhile advanced to v1.0.3 / ayama-v0.1.3. This commit: 1. Sync all source-of-truth version files to the currently released versions (1.0.3, 0.1.3) and drop the now-stale 'rc2' prerelease tag — every public release shipped so far has been stable. 2. Add x-release-please-{major,minor,patch,version} marker comments on the four lines release-please needs to rewrite on each future release. The markers stay inert at compile time (they sit inside trailing `# ...` / `// ...` comments). 3. Create apps/ayama/core/include/ayama/version.hpp mirroring the framework's version.hpp — same MAJOR/MINOR/PATCH/MAKE_VERSION/STRING macros. Lives under ayama_core which already exposes its include dir as PUBLIC, so ayama-ui / ayama-cli / ayama-agent pick it up transitively. 4. Populate `extra-files` in release-please-config.json so the release PR rewrites all four files in lock-step with the manifest bump. After this lands, a `fix:` or `feat:` commit to main triggers a release-please PR that updates BOTH the manifest AND the in-source version constants. Merging that PR tags the commit; release.yml / release-ayama.yml then build a ZIP whose .exe knows its own version at runtime — the foundation for the upcoming "check for updates" feature in ayama-ui (PR forthcoming). Verified locally: ayama-ui.exe links clean on MinGW gcc 15.2 with the new headers. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Swately
force-pushed
the
feat/release-please-extra-files
branch
from
c8ebbc9 to
5a9de4f
Compare
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
release-please was installed in #9 but its
extra-filesarrays were empty — it only bumped.release-please-manifest.jsonon each release, leaving the actual source-of-truth version constants stale.Current state of versions before this PR:
.release-please-manifest.json(phyriad)1.0.3.release-please-manifest.json(ayama)0.1.3framework/_meta/include/phyriad/version.hpp1.0.0CMakeLists.txt(root)VERSION 1.0.0+rc2apps/ayama/CMakeLists.txtVERSION 0.1.0Result: every binary in the v1.0.3 ZIPs reports its compile-time version as
1.0.0. The upcoming "check for updates" feature would always report "update available" because the embedded version is wrong.Fix
1.0.3/0.1.3) and drop the stalerc2tag.# x-release-please-version,// x-release-please-major/minor/patchon the lines release-please needs to rewrite. They sit inside trailing comments — zero compile-time impact.apps/ayama/core/include/ayama/version.hppmirroring the framework's. Lives inayama_corewhich already exposes its include dir as PUBLIC, so all Ayama binaries pick it up transitively.extra-filesinrelease-please-config.jsonfor both packages.After this lands
A
fix:orfeat:commit onmaintriggers a release-please PR that bumps:.release-please-manifest.jsonCHANGELOG.mdCMakeLists.txt(root or ayama, depending on which package bumped)framework/_meta/include/phyriad/version.hpp(phyriad bump)apps/ayama/core/include/ayama/version.hpp(ayama bump)All in lock-step. Merging the PR tags the commit; existing release.yml / release-ayama.yml workflows take over and ship the ZIP.
Foundation for the version-check feature
With versions now embedded reliably in compiled binaries, the upcoming
ayama-uifeature canGET https://api.github.com/repos/Swately/phyriad/releasesand compareAYAMA_VERSION_STRINGto the latestayama-v*tag.Test plan
feat:/fix:commit verifies release-please rewrites all four files in its PR.🤖 Generated with Claude Code